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1.0 


INTRODUCTION 


Juantitative  techniques  for  describing  and  evaluating  software 
systems  have  been  developed  on  a  largely  aa  hoc  basis.  The  need  for 
control  over  the  software  development  process  has  created  a  software 
engineering  discipline  whose  purpose  is  to  establish  operational  pro¬ 
cedures  for  the  development  of  quality  software.  Unfortunately,  tech¬ 
niques  for  predicting  and  evaluating  software  quality  and  performance  are 
just  emerging  for  practical  application.  Computer  science  and  software 
engineering  need  metrics  to  help  quantify  the  various  aspects  of  software 
development.  This  report  summarizes  and  explains  some  metrics  from 
current  literature. 


The  emphasis  of  this  report  is  the  review  of  software  metrics  as 
they  may  be  applied  to  the  maintainability,  supportability,  and  testabil¬ 
ity  of  software. In  particular,  the  metrics  suggested  by  Halstead, 
McCabe,  and  Woodward  ot  al ,  are  reviewed.  However,  metrics  of  a  more 
general  nature  are  presented  for  completeness,  consideration,  and  as  a 
historical  background.  The  following  software  metrics  are  summarized. 

X 

1)  Halstead's  Software  Sciences 

2)  McCabe's  Complexity  Metrics 

3)  Woodward,  Hennel ,  and  Hedley's  Knots  Complexity 

4)  Gilb's  Software  Metrics 

5)  Boehm,  Lipow,  and  Brown’s  Software  Metrics 

6)  Thayer's  Reliability  Metrics 

7)  McCall's  Software  Metric  Approach  (see  Section  on  Boehm) 


8)  Myers'  Extension  to  McCabe's  Complexity 


The  emphasis  for  software  metrics  discussed  here  is  placed  on 
module  complexity.  Recommendations  are  included  for  the  near  term  use  of 
metrics  for  software  assessment.  A  subsequent  report  will  address  module 
strength,  cohesion,  and  inter-connectivity.. 

1.1  So ftware  Complexity 


The  measurement  of  software  complexity  has  received  increased 
attention,  since  software  costs  have  increased  in  proportion  to  total 
computer  system  costs.  Heretofore,  complexity  has  been  a  loosely  defined 
term,  and  neither  Boehm  or  McCall  included  it  directly  among  their 
metrics  for  software  quality. 

Two  separate  focuses  have  emerged  in  studying  software  com¬ 
plexity:  commputational  and  psychological  complexity.  Computational 

complexity  relies  on  the  formal  mathematical  analysis  of  such  problems  as 
algorithm  efficiency  and  use  of  machine  resources.  In  contrast  to  this 
formal  analysis,  the  empirical  study  of  psychological  complexity  has 
emerged  from  the  understanding  that  software  development  and  maintenance 
are  largely  human  activities.  Psychological  complexity  is  concerned  with 
the  characteri sties  of  software  which  affect  programmer  performance. 
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USES  OF  SOFTWARE  METRICS 


The  measurement  of  software  complexity  Is  one  facet  of  a  larger 
effort  to  measure  important  software  characteristics.  Measurements  of 
software  characteristics  can  provide  valuable  information  throughout  the 
software  life  cycle.  During  development,  measurements  can  be  used  to  predict 
the  resources  which  will  be  required  in  future  phases  of  a  project.  For 
instance,  metrics  determined  from  the  detailed  design  can  be  used  to  predict 
the  amount  of  effort  that  will  be  required  to  implement  and  test  the  code. 
Metrics  determined  from  the  code  can  be  used  to  predict  the  number  of  errors 
that  may  be  found  in  subsequent  testing  or  the  difficulty  involved  in  the 
maintainability  and  supportability  of  a  section  of  code.  Metrics  should  be 
utilized  during  software  testing  to  assess  the  complexity  and  the  quality  of 
software. 


Software  metrics  can  be  used  in  at  least  three  ways  during  the 
software  lifecycle: 

Management  Information  Tools 


As  a  management  tool,  metrics  provide  several  types  of  information 
for  prediction  and  assessment.  Measurements  can  be  developed  for 
costing  and  sizing  at  the  project  level  and  for  estimating  produc¬ 
tivity.  Such  metrics  allow  managers  to  assess  progress,  future 
problems,  and  resource  requirements.  If  these  metrics  can  be  proven 
reliable  and  valid  indicators  of  development  processes,  they  provide 
an  excellent  source  of  management  vision  into  a  software  project. 

Measures  of  Software  Quality 

Interest  grows  in  creating  quantifiable  criteria  against  which  a 
software  product  can  be  judged.  An  example  criteria  would  be  the 
minimally  acceptable  mean  time  between  software  failures  or  the  time 
required  to  modify  a  module.  These  criteria  could  be  used  as  either 
acceptance  standards  by  a  software  acquisition  manager  or  as  guidance 
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acceptance  standards  by  a  software  acquisition  manager  or  as  guidance 
to  potential  problems  in  the  code  during  software  validation  and 
veri fi cation. 

Feedback  to  Software  Personnel 


Software  complexity  metrics  may  be  used  to  provide  feedback  to 
programmers  about  their  code.  When  a  section  of  software  grows  too 
complex,  the  code  may  be  redesigned  until  metric  values  are  brought 
within  acceptable  limits  or  the  complexity  is  justified. 

Software  metrics  may  be  di fferentiated  between  measures  of  process 
and  measures  of  product.  Measures  of  process  would  include  the  resource 
estimation  metrics  described  as  potential  management  tools.  However,  measures 
of  process  convey  little  information  about  the  actual  state  of  the  software 
product.  Measures  of  the  product  represent  software  characteri sties  as  they 
exist  at  a  given  time,  but  do  not  indicate  how  the  software  has  evolved  into 
this  state.  Measures  used  for  feedback  to  programmers  or  to  assess  quality  of 
software  are  measures  of  product.  The  latter  metrics  are  of  primary  concern  to 
software  assessment  efforts. 
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HALSTEAD'S  SOFTWARE  SCIENCE 


The  theory  of  software  science  as  presented  by  Halstead  in  his  1977 
book,  Elements  of  Software  Science[l],  is  summarized  here.  Halstead's  theory 
is  probably  the  best  known  and  the  most  thoroughly  studied  measures  of 
software  complexity.  A  computer  program  is  considered  in  software  science  to 
be  a  serie:  of  tokens  which  can  be  classified  as  either  "operators”  or 
"operands".  AH  software  science  measures  are  functions  of  the  counts  of 
these  tokens.  The  oasic  units  are  defined  as 

n.  =  number  of  unique  operators 

n*  »  number  of  unique  operands 

N,  -  total  occurrences  of  operators 

N^  3  total  occurrences  of  operands. 

Generally,  any  symbol  or  keyword  in  a  program  that  specifies  an  al¬ 
gorithmic  action  is  considered  an  operator,  while  a  symbol  used  to  represent, 
data  is  considered  an  operand.  Most  punctuation  marks  are  also  categorized  as 
operators.  This  is  illustrated  in  the  example  presented  below  in  Section  3.2. 
The  size  of  the  vocabulary  of  a  program,  which  consists  of  the  number  of 
unique  tokens  used  to  build  a  program,  is  defined  as: 

n  *  nl  +  n2. 

The  length  of  the  program  in  terms  of  the  total  number  of  tokens  used  is: 

N  »  Nl  +  N2‘ 

It  should  be  noted  tnat  N  is  closely  related  to  the  traditional 
"lines  of  code"  (LOC)  measure  of  program  length.  For  machine  language 
programs  where  each  line  consists  of  one  operator  and  one  operand,  N  »  2  X 
LOC. 


Software  metrics  are  defined  using  these  basic  terms.  Of  interest  is 
another  measure  for  the  size  cf  the  program,  called  the  volume: 

V  »  N  x  log2  n. 
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The  unit  of  measurement  of  volume  is  the  common  unit  for  size— "bits."  It  is 
the  actual  size  of  a  program  in  a  computer  if  a  uniform  binary  encoding  for 
the  vocabulary  is  used.  Volume  may  also  be  interpreted  as  the  number  of 
mental  comparisons  needed  to  write  a  program  of  length  N,  assuming  a  binary 
search  method  is  used  to  select  a  member  of  the  vocabulary  of  size  n.  Since 
an  algorithm  may  be  implemented  by  many  different  but  equivalent  programs,  a 
program  that  is  minimal  in  size  is  said  to  have  the  potential  volume  V*.  Any 
given  program  with  volume  V  is  considered  to  be  implemented  at  the  program 
level  L,  which  is  defined  by 

L  =  Y*/V • 

The  value  of  L  ranges  between  zero  and  one,  with  L  =  '  representing  a  program 
written  at  the  highest  possible  level  (i.e.,  with  minimum  size).  The  inverse 
of  the  program  level  is  termed  the  difficulty.  That  is, 

L  =  1/L . 

As  the  volume  of  an  implementation  of  a  program  increases,  the  program  level 
decreases  and  the  difficulty  increases.  Thus,  programming  practices  such  as 
the  redundant  usage  of  operands,  or  the  failure  to  use  higher  level  control 
constructs  will  tend  to  increase  the  volume  as  well  as  the  difficulty. 

The  effort  required  to  implement  a  computer  program  increases  as  the 
size  of  the  program  increases.  It  also  takes  more  effort  to  implement  a 
program  at  a  lower  level  (higher  difficulty)  when  compared  with  another 
equivalent  program  at  a  higher  level  (lower  difficulty).  Thus  the  effort  in 
software  science  is  defined  as 

E  3  Y/L  =  0  x  V. 

The  unit  of  measurement  of  E  is  "elementary  mental  discriminations." 

A  sound  theory  should  have  not  only  an  intuitive  set  of  definitions, 
but  should  also  contain  an  intuitive  model  for  which  a  useful  set  of  hypoth¬ 
eses  may  be  derived  and  validated.  The  model,  although  never  explicitly 
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stated  by  Halstead,  is  that  most  programs  are  produced  by  concentrating 
programmers  through  a  process  of  mental  manipulation  of  the  unique  operators 
and  operands.  The  basic  assumption  that  leads  to  the  hypotheses  presented  in 
the  following  subsections  is  an  implicit  limit  on  the  mental  capacity  of  a 
programmer. 

3 . 1  List  of  Halstead's  Metrics 

A  compendium  of  Halstead's  metrics  is  presented  in  Table  3-1.  For 
further  explanation  of  the  definitions  and  terms,  the  reader  is  referred  to 
Elements  of  Software  Science  by  Halstead. 


Length  Equation 

a.  .V  =  n,  log,  n,  ♦  n,  iog,  n , 

Volume  Metric 

b.  V  *  ,V  log,  n 

Potential  Volume 

c.  V  *  (2  ♦«,•)  log, (2  -  n,  *1 

Boundary  Volume 

d.  V  '•  a  (2  *  «,*  log,  /»,*)  log,  (2  *■«,*> 

Relations  between  Operacors  and  Operands 
el  A  *(»'••-»'•)/  V 
<2  B  =  > -  2  (K--  -  V')1V 
eJ  n,  *  A  n,  *  B 

e-»  A  =■  ( <«,  *)/(/!, '  i-  2))  log,  (n.V2l 
3  =  -i,*  -  2 A 

Program  Level 

I  I  4  *  VIV 

12.  4 ‘  =  ((/itV«,)  Mn,//V.  ) 

13  4  s  r-t'/n, 

(A  4  =  n,/rV, 

Intelligence  Count 

gl  /  *  4‘ X  K 

g2.  /  *  (  (2/n,  )(n,//V,  )  M/V,  *  ,V,  )  log,  (|V,  mi,| 

Programming  Effort 
hi  f  »  R/4 

T ime  Equation 

i  I  7”  *  in,  iV,  (n,  log,  n,  »«,  tog,  n, I  log,  u  |/2  n, 

Language  Level 

1 1  V  =  41" 

|2  '  -  4(4  <  *  4  squared  times  • 

l  une  I’.jiiaiion 

r  -  47. V 

I  iror  l’i|ujlion 

/  •  (  I"  I  Miuaicil  limes  a  squared 

n  4/4(0) 

where  ‘  (<))  mcjn  no  ol  elcmeitljiv  .liurmiiiutumi 

t*c i we,- ii  njiti.il  errors  m  progr ainmuig  .mil  //  no  delivered  errors 


Table  3-1.  Hastead's  Metrics 
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3.2 


Description  of  Operators  and  Operands 


Halstead  has  defined  relationships  between  the  number  of  operator  and 
operand  counts  in  an  alogrithm  to  determine  several  quality  factors  of  the 
related  software.  The  units  from  which  Halstead's  metrics  are  defined 
(operators  (^n^  and  operands  (02))  can  be  determined  by  an  automated  basis. 
The  following  example  illustrates  what  is  meant  by  Halstead's  operator  and 
operand  count. 


Interchange  Sort  Program 


10 

20 


SUBROUTINE  SORT  (X.N) 

DIMENSION  X{ N) 

IF  ( N.LT.2 )  RETURN 
DO  20  1-2. N 
DO  10  J=i ,1 

IF  ( X ( I ) . GE . X ( J ) ) GO  TO  10 
SAVE=X( I ) 

X  ( I )  -  X  ( J  ) 

X(J)=SAVE 

CONTINUE 

CONTINUE 

RETURN 

END 


H 


Operator  Count  and 

Frequency  of  Use 

Operator 

Frequency 

t 

1  End  of  statement 

7 

2  Array  subscript 

6 

f 

3  = 

5 

4  1F(  ) 

2 

5  DO 

2 

6  . 

7  End  of  program 

2 

1 

1- 

8  .LT. 

1 

9  .GE. 

1 

10  GO  TO  10 

1 

28=N1 

1 

Operand  Count  and  Frequency  of  Usg 


Operand 

Frequency 

-■ 

1  X 

6 

2  I 

5 

3  J 

4 

4  h 

2 

-- 

5  2 

2 

6  SAVE 

2 

7  1 

1 

22SN~ 

* 
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To  determine  the  programming  effort,  E,  the  following  steps  would  be 
exercised: 

U)  Compute  the  Volume  Metric,  V 
V  =  N  x  log^n 

( 

(2)  Determine  an  estimate  of  the  program  level,  L 

.  2  n2 

L  =  nT  x  TJ7 

(3)  Compute  Programming  Effort,  E 

E  =  V/L 


3.3  Program  Difficulty  Used  to  Support  Testability 

Of  the  relationships  defined,  the  predicted  difficulty,  D,  is  the  one 
best  correlated  to  actual  data  and  most  useful  for  test.  The  formula  des¬ 
cribing  difficulty  may  be  expressed  as: 


Difficulty  then,  is  the  product  of  two  ratios,  nl/2  which  increases  with  the 

number  of  operators  used,  and  N2/n2  which  1 s  the  avera9e  operand  useage.  The 
more  times  an  operand  is  used,  the  greater  the  likelihood  for  error  and  the 
larger  the  resulting  value  of  D.  Thus  as  D  increases,  the  error  proneness  of 
the  program  increases. 

An  average  number  of  operators  can  be  determined  for  the  system  and  an  operand 
useage  determined.  By  using  these  values,  a  lower  bound  of  acceptability  for 
D  is  determined.  If  the  standard  deviation  of  n^  js  adcje(j  to  the  average 
number  of  operators  and  0  recomputed,  the  upper  limit  of  D  is  fixed. 
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A  study  at  IBM  using  30  program  modules  quantified  D  for  PL/S  programs.  In 
these  programs,  the  average  value  of  nl  was  46,  the  ratio  N2/n2  was  approxi¬ 
mately  5  and  the  standard  deviation  of  nl  was  18.  These  values  yield  upper 
and  lower  limits  of  D  as  follows: 


I 

i 


f 

e 


* 


=  X  5  =  115  (lower  bound) 

1  2 

D  =  46  -i-  18  x  5  =  160  (upPer  bound) 

Z  2 

The  boundary  conditions  above  show  the  points  at  which  the  program  becomes 
suspect  due  to  "error-proneness" .  For  instance,  a  module  with  a  value  D 
greater  than  160  should  have  a  team  review  of  concepts  and  implementation.  A 
module  with  a  value  of  D  between  115  and  160  would  suggest  that  the  programmer 
needs  to  review  his  implementation.  For  d  less  than  115,  the  error-proneness 
of  the  program  is  acceptable. 


This  static  test,  when  applied  to  a  program  prior  to  test  should  prove  to  be  a 
I  valuable  tool  in  predicting  maintainability  of  software.  The  lower  the  value 

of  0,  the  more  maintainable  a  program  will  be. 
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3.4  Overall  Evaluation  of  Software  Science 

Halstead's  software  science  is  appealing,  much  of  the  experimental 
evidence  is  convincing,  and  the  psychological  foundations  are  reasonably 
sound.  It  is  reported  to  be  the  most  complete  attempt  at  the  quantitative 
evaluation  of  software.  However,  it  should  be  noted,  that  it  is  not  complete 
since  it  ignores  specific  issues,  such  as  choice  of  mnemonic  variable  names, 
comments,  control  flow  complexity,  and  data  structures.  Furthermore,  general 
issues,  such  as  portability,  flexibility,  and  efficiency  are  not  addressed. 


Halstead's  quantitative  metrics  have  had  only  limited  application  in 
actual  practice.  However,  Software  Science  shows  promise  as  a  quantitative 
tool  for  software  reliability,  software  development  and  maintenance  effort 
estimation.  Halstead's  work  should  be  included  in  testing  as  a  formal  measure 
of  complexity  and  possibly  modularity. 
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4.0 


McCABE'S  SOFTWARE  COMPLEXITY  METRICS 


Thomas  McCabe  proposed  three  metrics  in  IEEE  Transactions  on  Software 
Engineering  in  December  1976[2]:  cyclomatic,  essential,  and  actual  com¬ 
plexity.  All  three  are  based  on  a  graphical  representation  of  the  program 
being  tested.  The  first  two  metrics  are  calculated  from  the  program  graph, 
while  the  third  metric  is  calculated  at  run  time. 

4.1  Cyclomatic  Complexity 


McCabe  defines  cyclomatic  complexity  by  finding  the  graph  theoretical 
"basis  set."  In  graph  theory,  there  are  sets  of  linearly  independent  program 
paths  through  any  program  graph.  A  maximal  set  of  these  linearly  independent 
paths,  called  a  "basis  set,"  can  always  be  found.  Intuitively,  since  the 
Drogram  graph  and  any  path  through  the  graph  can  be  constructed  f *om  the  basis 
set,  the  size  of  this  basis  set  should  be  related  to  the  program  complexity. 
From  graph  theory,  the  cyclomatic  number  of  the  graph.  V(G),  is  given  by 

V  ( G )  =  e  -  n  +  p 

for  a  graph  G  with  number  of  nodes  n,  edges  e,  and  connected  components  p. 
For  further  explanation  of  the  definiton  and  terms,  the  reader  is  referred  to 
the  previous  cited  reference[2] .  The  number  of  linearly  independent  program 
paths  through  a  program  graph  is  V ( G )  +  p,  a  number  McCabe  calls  the 
cyclomatic  complexity  of  the  program.  Cyclomatic  complexity,  CV(G), 

where 

CV(G)  =  e  -  n  +  2p, 

can  then  be  calculated  from  the  program  graph.  In  the  graph  of  Figure  4-1, 

e  =  18,  n  =  14,  and  p  =  1. 

Thus 

V { G )  =  5  and  CV(G)  =  6. 


A  proper  subgraph  of  a  graph  G  is  a  collection  of  nodes  and  edges 
such  that,  if  an  edge  is  included  in  the  subgraph,  then  both  nodes  it  connects 
in  the  complete  graph  G  must  also  be  in  the  subgraph.  Any  flow  graph  can  be 
reduced  by  combining  sequential  single-entry,  single-exit  nodes  into  a  single 
node.  Structured  constructs  appear  in  a  program  graph  as  proper  subgraphs 
with  only  one  single-entry  node  whose  entering  edges  are  not  in  the  subgraph, 
and  with  only  one  single-exit  node,  whose  exiting  edges  are  aiso  not  included 
in  the  subgraph.  For  all  other  nodes,  all  connecting  edges  are  included  in 
the  subgraph.  This  single-entry,  single-exit  subgraph  can  then  be  reduced  to 
a  single  node. 


Figure  4-1.  Control  Flow  Graph 
4.2  Essential  Complexity 

Essential  complexity  is  a  measure  of  the  “unstructuredness"  of  a 
program.  The  degree  of  essential  complexity  depends  on  the  number  of 
single-entry,  single-exit  proper  subgraphs  containing  two  or  more  nodes. 


There  are  many  ways  in  which  to  form  these  subgraphs.  For  a  straight-line 
graph  (no  loops  and  no  branches),  it  is  possible  to  collect  the  nodes  and 
edges  to  form  from  i  to  n/2  (n  =  number  of  nodes)  single-entry,  single-exit 
subgraphs.  An  algorithm  can  be  developed  to  find  the  minimum  number,  m,  of 
such  subgraphs  in  a  graph. 

The  essential  complexity  E V ( G )  is  defined  as 

£V( G )  =  CV{ G )  -  m 


where  m  is  the  minimum  number  of  subgraphs  in  a  graph. 

Figure  4-2  is  an  example  of  a  program  graph  with  single-entry, 
single-exit  proper  subgraphs  identified  from  such  an  algorithm.  The  nodes  in 
the  two  proper  subgraphs  are  (7,  8,  9,  10,  11,  12,  13),  and  (9,  10,  11,  12). 
Note  that  the  second  subgraph  is  entirely  contained  within  the  first  subgraph. 
Thus  the  essential  complexity  is 


EV(G)  =  CV(G)  -2=4 

(  1 
i 


/  i 
•  \ 


Figure  4-2.  Reducible  Flow  Graph 
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The  program  graph  for  a  program  built  with  structured  constructs  will 
generally  be  decomposable  into  subgraphs  that  contain  single  entry  and  a 
single  exit.  The  minimum  number  of  such  proper  subgraphs  is  CV(G)  -  1. 
Hence,  the  essential  complexity  of  a  structured  program  is  1. 

4.3  Actual  Complexity 


Actual  complexity,  AV,  is  the  number  of  independent  paths  actually 
executed  by  a  program  running  on  a  test  data  set.  AV  is  always  loss  than  or 
equal  to  the  cyclomatic  complexity  and  is  similar  to  a  path  coverage  metric. 
A  testing  strategy  would  be  to  attempt  to  drive  AY  closer  to  CV(G)  by  finding 
test  data  which  cover  more  paths  or  by  eliminating  decision  nodes  and  reducing 
portions  of  the  program  to  in-line  code. 


5.0  KNOTS  COMPLEXITY  MEASURE 

The  "knots"  complexity  measure,  suggested  by  Woodward,  Hennel ,  and 
HedleyC3],  is  based  on  control  flow  arcs  drawn  on  the  actual  sequential  source 
program.  Essentially,  what  is  done  is  to  draw  arcs  from  every  explicit 
control  flow  operator  to  the  destination  of  that  transfer  of  control.  A 
"knot"  is  defined  to  occur  when  one  is  forced  to  draw  two  such  directional 
arcs  that  cross  each  other  at  some  point.  It  should  be  clear  that  the 
unrestricted  use  of  GO  TO  statements  allowing  the  production  of  the  much 
feared  "spaghetti"  code  will  have  a  high  number  of  knots. 

Knots  complexity  can  be  stated  more  mathematically  and  without 
ambiguity  as  follows.  Let  a  jump  from  line  a  to  line  b  be  represented  by  the 

ordered  pair  of  integers  (a.b).  Define  min  (a,b)  as  the  line  (a  or  b)  that 

appears  prior  to  the  other.  Similarly,  the  max  (a.b)  is  the  line  (a.b)  that 

appears  after  the  other.  As  an  example,  if  the  max  (a.b)  =  a,  the  jump  (a.b) 

is  a  backward  branch.  Then  the  jump  (p,q)  gives  rise  to  a  "knot"  or  crossing 
point  with  respect  to  jump  (a.b)  if  either 
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1)  mi n(  a ,b) <min(  p ,q) <max( a ,b) 
and  max{p,q)>max( a ,b) 


5.1 


Knots  Complexity  Using  How  Graphs 


The  definition  of  knots  is  dependent  on  knowledge  of  program  control 
flow  jumps  in  terms  of  line  numbers.  However,  it  is  possible  to  obtain  upper 
and  lower  bounds  on  the  number  of  knots  in  a  program  from  a  directed  graph 
representation  provided  we  also  know  the  ordering  of  the  nodes  to  make  the 
transition  from  a  two-dimensional  graph  to  a  one-dimensional  program.  (It 
should  be  noted  that  McCabe's  Complexity  is  not  dependent  on  the  "location"  of 
the  nodes  and  paths  within  the  code  cf  a  program.)  The  inability  to  extract 
the  precise  number  of-Jcnots  is  to  be  expected,  because  information  concerning 
— theTpihysical  source  text  is  discarded  in  constructing  a  directed  graph  of  a 
program. 


In  order  to  obtain  the  lower  bound  we  just  apply  the  definition  as  it 
stands,  where  now  the  ordered  pairs  on  integers  (a,b)  and  (p,q)  represent  the 
edges  of  the  directed  graph.  The  strict  inequalities  in  the  definition  ensure 
that  no  knots  arise  which  involve  transfer  of  control  to  the  next  node,  i.e., 
edges  (a,a+l).  This  is  an  example  of  the  transfer  of  control  via  natural 
succession.  Thus,  the  number  obtained  in  this  fashion  is  a  definite  lower 
bound. 


Since  the  nodes  in  a  directed  graph  usually  represent  basic  blocks 
which  may  involve  several  source  lines  with  a  unique  entry  point  at  the  head 
of  the  block  (first  line),  no  branching  within  the  block,  and  a  unique  exit 
point  at  the  tail  of  the  block  (last  line),  there  exist  situations  in  which 
there  is  insufficient  information  to  resolve  the  existence  or  nonexistence  of 
a  knot.  For  example  the  number  of  knots  in  a  construction  such  as  in  Figure 
5-2  depends  on  whether  node  3  corresponds  to  several  lines  (1  knot)  or  just 
one  line  (0  knots).  By  including  all  such  doubtful  cases  in  our  count  we  can 
obtain  an  upper  bound  to  the  number  of  knots. 
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B  corresponds  to 
just  l  line; 

0  knots 


B  corresponds  to 
more  than  1  line; 
1  knot 


Figure  5-2.  Knots  Determined  from  Directed  Graph 

Figure  5-2  shows  the  difficulty  in  determining  the  number  of  knots  in  a 
program  from  its  directed  graph  representation.  The  lower  and  upper  bounds 
for  knots  will  be  shown  separated  by  a  colon.  In  the  example  above,  the 
representation  would  be  0:1. 

It  is  to  be  noted  that  calculating  a  lower  bound  and  an  upper  bound 
in  this  way  provides  a  complexity  interval  in  a  manner  resembling  Myers' 
extension  of  McCabe's  cyclomatic  complexity  (Section  9). 

5 .2  Knots  and  Cyclomatic  Complexity 

One  of  the  advantages  the  knot  count  has  over  the  cyclomatic 
complexity  V(G)  is  that  the  number  of  knots  in  a  program  is  dependent  on  the 
ordering  of  the  statements  in  the  program.  Since  a  directed  graph,  i  ike  a 


IB 


flo*  chart,  is  two  dimensional ,  linearitation  of  it  must  take  place  in  the 

actual  construction  of  a  pro9ram.  There  -ill  he  man,  ways  of  ordering  the 

nodes  of  a  directed  graph  to  produce  equivalent  programs  and  some  will  he  more 

complex  than  others.  This  will  not  he  reflected  in  vfs)  since  McCabe's 

measure  is  independent  of  the  ordering.  Consider  an  example  of  reordering 

Figure  5-J  consisting  of  5  nodes  and  6  edges.  The  cyclomatic  complexity  is 
the  same  for  both  graphs. 

V(G)  =  6  -  5  +  2  =  3. 


I"  the  first  version,  the  knots  interval  is  3:4.  However,  the  second 
restructured  (less  complex)  version  has  a  knots  interval  of  i;i. 


Hgure  5-3.  An  Example  Of  Reduced  Complexity  By  Restructuring 
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Other  program  transformations  aimed  at  code  improvement  also  have  the 
desired  property  of  reducing  the  knot  count.  An  example  is  included  here  in 
Figures  5-4  and  5-5.  It  demonstrates  once  again  an  advantage  of  considering 
knots  rather  than  the  cyclcmatic  complexity  alone,  since  v(g)  =  3  for  both  the 
original  (Figure  5-3)  and  the  undoubtedly  less  complex  version  (Figure  5-4) 
which  has  no  “phantom1*  paths. 


.100 


4— f 


CALL  ABC 

IF  (ZR)  500,  500,  100 
CALL  DEF 


*-+150  IF  ( Z3)  200,  200,  550 

U.200 


4*  300 


■>  500 


550 


-*  2000 


ZG-ZG+1 

ZC=0 

CALL  HIJ 
CALL  OPQ 
GOTO  2000 
CONTINUE 
Z3=l 

GOTO  150 
CONTINUE 
CALL  RST 
ZB=ZB+1 
ZC=ZC+1 
■  GOTO  300 
RETURN 
END 


Figure  5-4.  Nine  Knot  Example 

Figure  5-4  shows  version  of  code  having  9  knots.  It  has  two  branch  creating 
statements  and  so  V (G )  *  2+1  3  3. 
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CALL  ABC 


500,  100 
200,  550 


Figure  5-5.  Three  Knot  Example 

Figure  5-5  shows  the  rewritten  version  of  code  having  no  "phantom"  paths  and  3 
knots.  It  still  has  two  branch  creating  statements  and  so  V(G)  =  2+1  =  3. 

5.3  Knots  Complexity  and  Structured  Programming 

Knots  complexity  may  be  used  to  evaluate  structured  programming. 
Since  the  number  of  knots  is  determined  from  the  program  text,  the  complexity 
of  the  usual  constructs  in  structured  programming  will  depend  upon  the 
language  used  and  the  way  the  constructs  are  implemented.  Consider  for 
example  the  implementation  in  Fortran  of  the  simple  choice  clause: 


if  bool  then  ...  A  ...  else  ...  B  .  . 


The  recommended  way  of  writing  this  in  Fortran  is  given  in  Figure 
5-6d  and  has  1  knot.  Another  way  of  implementing  this  construct  which  does 
not  involve  negation  of  the  Boolean  expression,  hut  results  in  more  compli- 
cated  control  flow,  is  given  in  Figure  5-6b  and  has  2  knots. 


-  IF  (.NOT. BOOL)  GO  TO  10 

- -  GO  TO  20 

■f - >"10  CONTINUE 

i 

^ 20  CONTINUE 

1  KNOT 
(a) 


- IF  (BOOL)  GO  TO  10 

- GO  TO  20 

— 9-10  CONTINUE 

- GO  TO  30 

— 3-  20  CONTINUE 

— 30  CONTINUE 

2  KNOTS 
(b) 


Mgure  5-6.  Implementation  of  IF-  IHEN-ELSE  in  Fortran 


The  use  of  the  Fortran  arithmetic  IF  or  computed  GOTO  to  provide  a 
3-wdy  choice  resulcs  in  3  knots  (Figure  5-7).  In  general,  an  n-way  case 
simulated  using  the  computed  GOTO  will  have  a  knot  count  of; 


k  = 


n_x_J  n  -  1 ) 
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The  while  and  repeat  until  looping  constructs  can  be  implemented  with  zero 
knots. 


•GO  TO  (10,20,30),  NCASE 


4*0  CONTINUE 


- GO  TO  40 

1 — >20  CONTINUE 
- GO  TO  40 


430  CONTINUE 


440  CONTINUE 


Figure  5-7.  Example  of  3-Way  Case  Construct 

The  contribution  to  the  program  complexity  arising  from  the  use  of 
structured  programming  can  be  removed  to  provide  a  measure  which  reflects  the 
lack  of  structure  in  a  program.  The  reduction  of  the  directed  graph  can  be 
performed  by  replacing  the  primitives  of  structured  programming  by  single 
nodes.  If  this  process  is  continued  until  no  further  reduction  of  the  graph 
is  possible  and  the  knots  interval  of  the  remaining  graph  G‘  is  determined, 
this  will  provide  a  measure  of  program  "unstructuredness."  A  structured 
program  will  be  reducible  to  a  single  node  with  zero  knots.  This  leads  to  a 
definition  of  the  remaining  knots  as  the  essential  knots  of  the  program  and  it 
can  be  stated  that  structured  program  will  have  zero  essential  knots.  This  is 
analogous  to  McCabe's  calculation  of  the  cyclomatic  complexity  of  the  reduced 
graph  V(G')  which  equals  his  essential  complexity  EY(G)  provided  each  proper 
subgraph  with  unique  entry  and  unique  exit  is  one  of  the  structured  pro¬ 
gramming  primitives.  Note  that,  'rom  Section  4, 

EV(G)  »  V(G')  *  1  for  a  structured  program. 
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6.0 


GIl.B'S  SOFTWARE  METRICS 


In  his  book  "Software  Metrics",  Gilb[4j  presents  a  set  of  basic 
software  metrics.,  making  no  claim  as  to  their  completeness.  He  emphasizes 
that  each  application  requires  its  own  concepts  or  tools  and  that  his  text  is 
intended  to  provide  basic  concepts  on  which  the  user  can  build.  Gilb  builds  a 
strong  and  convincing  case  for  precise  measurement  of  software  based  on  the 
history  of  the  physical  sciences.  Most  of  these  metrics  are  simply  ideas  of 
what  might  be  measured  in  software  evaluation.  They  are  neither  definitive 
nor  substantial.  They  are  included  here  since  they  present  some  interesting 
possibilities,  provide  a  good  compendium  of  definitions  for  software  metrics, 
and  is  a  pioneering  effort  in  the  field. 

Gilb  discusses  the  software  metrics  in  6  basic  categories: 

1)  Reliability 

2)  Flexibility 

3)  Structure 

4)  Performance 

5}  Resources 

6)  Diverse 

These  categories  are  summarized  in  the  following  sections. 

6.1  Reliability  Metrics 

Among  the  metrics  Gilb  mentions  is  program  reliability  metrics,  which 
he  defines  as  the  probability  that  a  given  program  operates  for  a  certain 
period  of  time  without  a  logical  error.  The  pragmatic  measure  for  program 
reliability  is  one  minus  the  ratio  of  inputs  causing  execution  failures  and 
the  total  number  of  inputs. 

Maintainability  (the  probability  that  a  failed  system  will  be 
restored  to  operable  condition  within  a  specified  time)  is  described  as  a 
function  of  system  design  (diagnostic  aids,  documentation,  recovery  pro¬ 
cedures),  personnel,  and  support  facilities  such  as  diagnostic  test  tools. 
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Repai rabil i ty  is  distinguished  from  maintainability  in  that  all 
resources  (tools,  people,  partp)  are  assmaed  to  be  immediately  available.  It 
depends  more  on  the  nature  of  the  object  being  repaired. 

The  characteristic  of  serviceability  (the  ease  or  difficulty  with 
which  a  system  can  be  repaired)  is  described  by  Gilb,  but  it  is  not  considered 
quantifiable  at  present.  It  is  related  to  repairability. 

Availability  of  a  system  is  computed  by  dividing  the  time  actually 
available  by  the  time  that  the  system  should  have  been  available.  Gilb 
defines  intrinsic  availability,  operational  availability,  and  use  avail¬ 
ability. 


The  attack  probability  is  an  expression  of  the  frequency  with  which 
latent  problems  occur.  Examples  of  attacks  are  sabo-age,  invalid  data  values, 
program  logic  errors,  or  even  a  breakdown  of  a  computer's  air  conditioning. 

Gilb  illustrates  a  scale  for  generating  a  risk  measure  for  a  database 
in  this  discussion  of  the  sensitivity  characteristic.  Related  characteristics 
include:  security  probability  (the  probability  of  rejecting  an  attack); 

integrity  probability  (probability  of  system  survival);  and  the  accessibility 
(ease  of  access  to  a  system)  or  security  measure. 

The  ratio  of  correct  data  to  all  data  is  given  by  Gilb  as  a  measure 
of  the  Accuracy  (freedom  from  error).  As  did  Boehm,  Brown  and  lipow[5],  Gilb 
states  that  accuracy  is  necessary  for  reliability.  Precision  is  defined  as 
the  degree  to  which  the  errors  tend  to  have  the  same  sort  of  cause.  Gilb 
measures  it  by  the  ratio  of  the  number  of  actual  bugs  at  the  source  to  the 
number  of  corresponding  root  bugs  observed  in  total  which  are  caused  by  source 
bugs.  For  example,  if  one  error  (bug)  causes  100  error  messages  during  a 
specific  time,  the  precision  equals  0.01. 


6.2 


Flexibility  Metrics 


Gilb's  second  category  is  flexibility  metrics  which  includes: 
logical  complexity,  built-in  complexity,  open-ended  flexibility  (adapt¬ 
ability),  tolerance  (of  system  input  variance),  generality,  portability,  and 
compatability.  For  the  logical  complexity,  Gilb  proposes  a  measure  of  ‘binary 
decisions'  in  the  logic.  Such  a  measurement  may  be  made  manually  or  auto¬ 
matically.  The  number  of  nonnormal  exits  from  a  decision  statement  gives  the 
absolute  logical  complexity.  Gilb  suggests  that  logical  complexity  has  been 
found  to  be  of  significance  in  predicting  the  cost  cf  computer  programs. 

Built-in  flexibility  (the  ability  of  a  system  to  handle  different 
logical  situations)  is  the  ratio  of  usable  complexity  to  total  complexity.  A 
built-in  flexibility  of  one  indicates  that  all  complexity  is  desired.  This 

measure  is  applicable  in  judging  the  suitability  of  software  packages  against 
a 1 ternati ves. 

Open  ended  flexibility  (or  the  measure  of  the  ease  with  which  new 
functions  can  be  added  to  a  system)  may  be  grossly  measured  by  counting  the 

linkages  between  modules.  Whether  or  not  this  indicator  is  meaningful  has  yet 
to  be  demonstrated. 


Tolerance  (the  ability  of  a  system  to  withstand  a  degree  of  variation 
in  Without  malfunction  or  rejection)  is  the  number  of  permissible  varia¬ 
tions  which  a  system  will  handle  'sensibly.'  Tolerance  may  be  designed  into  a 
system.  There  is,  however,  a  tradeoff  between  the  cost  of  tolerance  and  the 
cost  of  failure  due  to  lack  of  tolerance. 


Gilb's  metric  of  generality  (degree  to  which  a  system  is  applicable 
to  a  different  environment)  varies  between  0.0  and  1  (for  100  percent.). 

For  portability,  P(G),  (ease  with  which  a  system  can  be  moved  from 
one  environment  to  another)  Gilb  gives  the  following  measure: 
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P(G)  »  1  -  E(T)/E(R) 

where: 

E(T)  =  resources  needed  to  move  a  system  to  a  target 
environment; 

£(R)  =  resources  needed  to  create  the  system  for  the  resident 
environment. 

The  portability  concept  is  useful  in  evaluating  the  effectiveness  of  a  system 
that  is  expected  to  be  moved. 

Compatability  (the  measure  of  portability  that  can  be  expected  of 
systems  when  they  are  moved  from  one  given  environment  to  another)  must  be 
measured  by  average,  maximum,  and  minimum  portability  measures  because  only 
portability  (not  compatability)  is  measurable  in  practice. 

6.3  Structure  Metrics 


Gilb's  structure  metrics  include:  redundancy  ratio,  hierarchy, 
structural  complexity  (modularity)  and  simplicity,  and  distinctness. 

The  redundancy  characteristic  is  a  relative  one  which  is  measured  by 
the  ratio  of  a  quantity  for  the  system  being  measured  to  the  quantity  for  some 
reference  system.  A  redundancy  of  1.0  indicates  minimum  redundancy.  An  ex¬ 
ample  of  the  redundancy  ratio  follows.  If  a  code  for  a  series  of  1000  objects 
is  6  digits  000000-999999  then  the  digit  redundancy  is  6/3  or  2.0. 

Basic  measures  of  a  hierarchy  are:  depth  (number  of  levels);  total 
number  of  elements  or  nodes  in  the  hierarchy;  and  breadth  (number  of  elements 
at  one  level).  These  measures  are  related  to  those  of  structural  complexity 
which  is  measured  by  the  number  of  subsystems  or  modules  and  structural  sim¬ 
plicity  which  is  the  ratio  of  the  number  of  module  linkages  to  the  number  of 
modules.  The  usefulness  of  these  concepts  has  not  been  demonstrated  with 
quantitative  data.  Rather,  'intuitive'  reasoning  has  been  used  in  the  litera¬ 
ture  when  describing  these  concepts. 
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Gilb  defines  distinctness  as  a  measure  of  the  failure-point  indepen¬ 
dence  of  one  piece  of  software  with  that  of  another  piece  performing  the  same 
function.  The  measuring  tool  is  the  ratio  of  the  number  of  bugs  in  the  first 
module  alone  to  the  number  of  bugs  in  the  first  module  which  simul taneously 
occur  in  the  second.  The  following  classes  of  errors  are  purportedly  detec¬ 
table  and  correctable  using  distinct  software:  design  errors  leading  to 
system  errors,  resource  problems,  numeric  errors,  order  code  error,  timing 
errors,  data  transmission  and  software  errors. 

6.4  Performance  Metrics 

The  performance  metrics  described  by  Gilb  are:  efficiency,  effec¬ 
tiveness,  and  transformation. 

Efficiency  is  defined  as  the  ratio  of  useful  work  performed  to  the 
total  energy  expended,  while  effectiveness  is  a  group  measure  comparing: 
operational  reliability,  system  readiness  and  design  adequacy.  Efficiency  and 
effectiveness  are  tradeoffs  against  each  other.  For  example,  it  might  be  very 
effective  to  do  triple  verification  of  data  registration  by  operators  but  it 
would  be  very  inefficient. 

A  transformation  measure  is  the  energy  or  resources  needed  to  convert 
data  from  one  state  to  another.  The  measurement  may  be  in  such  terms  as 
money,  time,  personnel,  electricity,  or  logical  cycles.  The  measure  is  impor¬ 
tant  to  measure  the  effect  (in  performance!  of  changes  to  algorithms,  modules, 
etc. 

6.5  Resource  Metrics 

Gilb's  resource  metrics  are:  financial  datametrics,  time  resource 
datametrics,  and  space  metrics.  Financial  datametrics  include:  total  system 
cost,  incremental  costs,  capital  investments,  operational  costs,  and  return  on 
investment.  Time  resource  datametrics  include  measures  of  computer  time  and 
personnel  time.  Space  metrics  involve  the  amount  of  space  (bits,  words, 
characters,  etc)  for  storing  data. 


6.6 


Diverse  Metrics 


Finally,  Gilb  includes  diverse  metrics  of  information,  data,  evolu¬ 
tion,  and  stability.  Information  is  the  interpretation  of  data,  and  is  not 
directly  measurable.  Data  has  many  possible  forms  which  should  be  taken  into 
account  when  measuring.  Bits  are  useful  measures  of  data  when  relating  to 
machine  cost.  Evolution  (the  designed  characteristic  of  a  system  development 
which  involves  stepwise  change)  may  be  measured  by  such  indicators  as:  number 
of  program  instructions  changed;  percentage  of  instruction  manuals  changed; 
number  of  new  data  elements  in  a  database,  etc. 

Stability  (the  measure  of  lack  of  perceivable  change  in  spite  of  an 
occurrence  which  would  normally  cause  change)  is  given  as  a  percentage  of 
change  in  a  system  due  to  a  change  in  environment.  An  example  would  be  the 
percentage  of  the  original  number  of  payroll  programs  changed  due  to  a  change 
in  tax  laws. 


6.7  Summary  of  Gilb's  Metrics 

This  lengthy  enumeration  of  metrics  is  more  provocative  than  produc¬ 
tive.  Gilb's  work  does  open  up  ideas  to  fresh  possibilities,  but  the  reality 
of  applying  many  of  these  ideas  is  disheartening.  Many  of  the  metrics  are 
difficult  to  obtain,  and  even  if  we  can  compute  a  value,  we  have  no  sense  of 
the  range  of  good  values.  The  lack  of  independence  of  the  metrics  adds  to  the 
confusing  complexity  and  makes  it  difficult  for  programmers  to  predict  the 
effect  of  a  program  change  on  a  group  of  metrics. 
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7.0 


BOEHM'S  QUANTITIVE  EVALUATION  OF  S/W  QUALITY 


Boehm  has  developed  a  set  of  S/W  quality  characteri sties  that  are 
subjectively  interrelated  to  a  set  of  metrics  which  are  quantifiable  and  thus 
can  provide  a  measure  of  S/W  quality.  These  are  best  expressed  in  the  form  of 
a  tree. 

The  elements  of  the  tree,  such  as: 


are  related  in  the  direction  of  the  arrows,  i.e.  if  a  program  is  maintainable, 
it  must  be  both  understandable  and  testable. 

It  would  follow,  then,  that  a  lower  level  of  primitive  concepts  exist  below 
undertandability  and  testability  that  are  quantifiable  (metrics).  These  are 
expressed  as: 


The  tree  illustrates  a  logical  progression  of  evaluating  a  conceptual  quality 
Dy  assigning  a  quantitative  numerical  value  to  measureable  metrics. 

The  degree  of  correlation  of  the  metrics  selected  to  the  element  of  software 
quality  that  we  wish  to  quantify  becomes  important,  since  if  the  correlation 
is  not  high,  the  values  attained  by  use  of  metrics  are  of  questionable  benefit 
to  the  evaluator. 

Add  i  t  i  ona  1  ly  ,  if  the  metric  cannot  lie  quantified  using  a  cost-effective 
method,  the  benefits  of  using  S/W  metrics  is  low.  Automating  the  quantifica¬ 
tion  of  metrics  ranges  from  stra ight foreward  and  trivial  to  virtually  impos¬ 
sible.  For  example,  counting  average  module  length  is  straightforward,  but 


judging  descripti veoess  of  material  is  very  difficult.  Table  7.1  presents  a 
summary  of  metrics  and  some  of  their  characteristics. 


Table  7.1.  Evaluation  of  Metrics  (Ref.  5) 


Primitive 

Characterise 

:s  Definition  of  Metrics 

Corielatlon 
wi  th 

Dual Ity 

Potential 
8enef 1 t 

Quanti  fl- 
abil 1 ty 

Ease  of 
Develop,  19 
Automated 
Evaluation 

Complete¬ 
ness  of 
Automated 

Eva luatlon 

Device- 

Independence 

0 1  - 1 

Are  computations  Independent  of  com¬ 
puter  word  sire  for  achievement  of 
reoulred  precision  or  storaoe  scheme? 

A 

5 

AL  ♦  EX 

♦  ri 

E 

P 

01-2 

i 

1 

Have  machine-dependent  statements 
been  flagged  and  commented  (e.g.. 
these  computations  which  depend  upon 
computer  hardware  capability  for  ad¬ 
dressing  half  words,  bytes,  selected 
bit  patterns,  or  those  which  employ 
extended  source  lanquage  features)? 

A 

5 

AL 

M 

P 

pel  f- 

iConta Inedness 

I  SC-l 

i 

Ooes  the  program  contain  a  facility 
for  Initialising  core  storage  prior 
to  use? 

A 

5 

AL 

£ 

P 

i 

!  SC-2 

1 

L _ 

6oes  the  program  contain  a  facility 
for  proper  positioning  of  input/ 
output  device's  prior  to  use? 

A 

5 

CC 

- E - 

p  i 

i 

j 

j 

i 

'Accuracy 
|  AR  - 1 

i 

l_ _ 

Are  the  numerical  methods  used  by 
the  program  consistent  with  appli¬ 
cation  retirements? 

A 

s 

n 

i 

! 

1 

I 

i HJRTj 

1 

1 

l_ - - J 

Are  the  accuracies  of  program  con¬ 
stants  and  tabular  values  consis¬ 
tent  with  apolicatlon  requirements? 

l 

M 

s 

al  ♦  n 

E 

p - j 

i 

j 

Completeness 
CP- 1 

- nn - 

Are  all  program  Inputs  used  within 
the  program  or  their  presence 
exolained  by  a  comment? 

U 

3 

AL 

. 

f 

C  ! 

i 

j 

<.?-t 

— _ 

Art  there  no  ’dunmy1'  subprograms 
referenced? 

s 

2 

AL 

- E - 

c  1 

1 

Robustness 

Ooes  the  orogram  have  the  capabil¬ 
ity  to  assign  default  values  to 
non-vpecified  oirameters? 

A 

5 

AL  ♦  TI 

E 

1 

p 

1 

i 

Is  input  data  checked  for  range 
errors  ? 

AA 

5 

al  *  n 

E 

p 

j 

Consistency  j 
CS  l 

- 

Are  all  sped ficatlons  of  sets  of 
global  variables  (i.e..  those  ap¬ 
pearing  In  two  or  more  subpro¬ 
grams)  identical  (e.g..  labeled 

COMMON? 

AA 

4 

AL 

E 

c  ! 

Is  tne  type  (e.g.,  real.  Integer, 
etc.)  of  a  variable  consistent 
fc r  all  uses? 

- S - 

~ 5 - 

31 - 

E 

P 

1.  Correlation  with  Software  Quality, 


r? 


A  -  Very  high  positive  correlation;  nearly  all  programs  with  a  high 
metric  score  will  possess  the  associated  characteristic. 

AA  -  High  positive  correlation;  a  good  majority  (say  75-90%)  of  all 
programs  with  a  high  metric  score  will  possess  the  associated 
characteristic. 

U  -  Usually  (say  50-75%)  of  all  programs  with  a  high  metric  score 
will  possess  the  associated  characteristic. 

S  -  Some  programs  with  high  metric  scores  will  possess  the  associ¬ 
ated  characteristic. 

2.  Potential  Benefit  of  Metrics. 


5  -  Extremely  important  for  metric  to  have  a  high  score;  major 
potential  troubles  otherwise. 

4  -  Important  for  metric  to  have  a  high  score. 

3  -  Fairly  important  for  metric  to  have  a  high  score. 

2  -  Some  incremental  value  for  metric  to  have  high  score. 

1  -  Slight  incremental  value  for  metric  to  have  high  score;  no  real 
loss  otherwise. 
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3.  Metric  Quant i fiabi 1 i ty  and  Feasibility  of  Automated 
Evaluation. 

AL  -  Can  be  done  cost-effectively  via  an  automated  algorithm. 

CC  -  Can  be  done  cost-effecti vely  via  an  automated  compliance  checker 
if  given  a  checklist  (Code  Auditor  is  such  a  tool). 

UI  -  Requires  an  untrained  inspector 

TI  -  Requires  a  trained  inspector 

El  -  Requires  an  expert  inspector 

EX  -  Requires  program  to  be  executed 

Ease  of  Developing  Automated  Evaluation 

E  -  Easy  to  develop  automated  algorithm  or  compliance  checker. 

M  -  Moderately  difficult  to  develop  automated  a’gorithm  or  compli¬ 
ance  checker. 

D  -  Difficult  to  develop  automated  algorithm  or  compliance  checker. 
Completeness  of  Automated  Evaluation 

C  -  Algorithm  or  checker  provides  total  evaluation  of  metric. 

P  -  Algorithm  or  checker  provides  partial  evaluation  of  metric. 

I  -  Algorithm  or  checker  provides  inconclusive  results. 
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Only  a  few  of  the  candidate  metrics  are  displayed  in  Table  7-1,  and  this  does 
not  imply  a  complete  listing  of  available  metrics  for  measuring  the  primitives 
defined  by  8oehm. 


An  expansion  of  Boehm's  work  was  done  by  McCall,  et  al[9],  and  the  list  of 
quality  factors  was  expanded  from  7  to  11  (Figure  7-2),  which  is  generally 
accepted  as  complete  today. 


Figure  7-2.  Software  Quality  Comparisons  (Ref.  7) 

The  work  by  Uoehm[5]  and  McCall[9]  address  the  measurement  of 
subjective  qualities  of  software  programs  by  breaking  broad  terms  down  into 
measurable 

and  testable  items.  The  list  of  metrics  presented  by  McCall  parallels  Boehms 
work  so  closely  that  only  a  comparison  of  the  results  are  presented  here. 


8.0 


THAYER'S  SOFTWARE  RELIABILITY 


Thayer[6]  has  taken  existing  S/W  reliability  models  and  correlated 
the  error  history  of  several  programs  to  produce  a  reliability  prediction 
using  established  mathematical  models.  The  data  collection  is  during  the  test 
phases  of  the  software  life  cycle.  Figure  8-1,  from  Thayer,  illustrates  the 
software  life  cycle  and  where  problem  reporting  and  error  data  is  collected. 


Figure  8-1.  Oata  Availability  Throughout  the  Software  Development  Cycle  (Ref.  6) 

The  concept  of  evaluation  of  S/W  error  data  has  evolved  to  a  com¬ 
prehensive  short  listing  that  is  easy  to  use  and  understand.  The  evolution  to 
Thayer's  list  of  major  error  categories  is  shown  in  Table  8-1.  The  first 
column  depicts  the  number  of  major  error  categories  and  column  2  shows  the 
total  of  the  detailed  error  categories. 
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Table  8.1.  History  of  Error  Category  Lists  (Ref.  6) 


(  Major 
Categories 

Oeta  <  1  ed 
Categories 

1  teratlon 

Comments 

13 

0 

Study  done  In  support 
of  CCIP-SS 

•  Entirely 
symptomatic 

1J 

224 

Post-CCIP-85  In-house 
work 

•  Greater  emphasis 
on  cause 

•  Failed  to 
recognize  code 
types 

20 

164 

Interim  technical  report 
for  Software  Bel  lability 
Study 

•  Predominately 
symptomatic 

•  Recognized 
types  of  code 

•  Assignment  not 
by  problem 
fixer 

25 

435 

Early  causa 'ive  work 

•  Generated  by 
specu  lation 

•  Long  with 
redundancies 

•  Hard  to  use 

12 

79 

Final  causative  list 

e  Comprehensive 
out  short 

c  Easy  to  use 

•  Problem  fixer 
assigns 
categories 

Thayer's  list  of  1 2  major  error  categories  and  the  number  of  detailed 
categories  in  each  are: 


(1) 

(2) 

(3) 

(4) 

(5) 

(6) 
(7) 


Computational  errors  -  contains  9  detail  categories. 
Logic  errors  -  contains  7  detail  categories. 

Data  input  errors  -  contains  6  detail  categories. 

Data  handling  errors  -  contains  lOdetail  categories. 
Data  output  errors  -  contains  8  detail  categories, 
interface  errors  -  contains  7  detail  categories. 

Data  Definition  errors  -  contains  4  detail  categories. 


(8)  Data  base  errors  -  contains  3  detail  categories. 

(9)  Operation  errors  -  contains  6  detail  categories. 

(10)  Other  -  contains  9  miscellaneous  detail  categories. 

(11)  Documentation  errors  -  contains  5  detail  categories. 

(12)  Problem  report  Rejection  -  contains  5  detail  categories. 


The  problems  reported  by  Thayer,  et  al,  in  data  collection  and 
analysis  are  equally  valid  for  forms  of  data  collection  other  than  error 
history  and  are  well  worth  noting: 


Table  8.2.  Data  Collection  and  Analysis  Problems  (Ref.  6) 


1.  Projects,  the  software,  and  tfie  data  vary  considerably  and 
are  not  descrlbable  In  common  terminology. 

2.  Oata  collection  can  represent  cost,  schedule,  and  manpower 
Impediments  to  software  de-elcpment  projects.  The  impact 
or  cost  considerations  of  data  collection,  although  real, 
are  not  fully  appreciated.  • 

3.  Oata  collection  fs  a  lot  of  work.  The  tools  and  techniques 
for  collecting  data  are  not  available. 

<.  Certain  data  Items  are  perishab’e  and  must  be  collected  and 
analyzed  when  they  become  available,  not  after  the  fact. 

5.  Performers,  project  management,  and  even  the  buyers  of  soft¬ 
ware  are  sensitive  aOout  providing  data  that  might  be  used 
to  adversely  evaluate  the  project  by  external  agencies. 

6.  Some  projects  produce  data  that  are  classified. 

7.  Analysis  techniques  and  questions  to  ask  of  the  data  are  not 
well  known. 

3.  There  is  no  quarantee  that  data  will  be  collected  (i.e.,  no 
requirement  for  projects  to  collect  data). 

3.  Data  accuracy  is  a  chronic  question. 

10.  Analysis  is  often  incomplete  or  inaccurate  if  proper  conmuni- 
cation  with  project  performers  is  not  established. 

11.  Contractor  and  customer  representatives  of  project  manage¬ 
ment  are  not  aware  of  the  benefits  of  data  analysis  and 
therefore  tend  not  to  support  it. 

12.  Project  structure  is  generally  not  tailored  to  use  available 
data  (i.e.,  the  mechanism  for  analyzing  data  and  folding 
results  back  into  the  project  fs  not  provided). 

13.  The  fervor  of  data  collection  inspires  data  gathering  that 
is  non-supporti  ve  of  the  software  development  process. 

U.  Some  data  elements  reauire  protection  to  preserve  the  privacy 
of  the  contributor  (e.g.,  cost  data). 

IS.  Oata  collection  is  commonly  thought  to  be  "not  necessary' 
to  a  properly  managed  projec* 

IS.  Project  organizational  structure  and  resources  vary,  making 
Consistent,  awl  ti  -project  data  collection  questionable. 

17.  Definition  of  which  parameters  are  needed  and  meaningful  to 
collect  Is  in  its  Infancy. 

18-  Presently  Implemented  data  collection  schemes  often  fail  to 
gather  data  fn  sufficient  detail,  making  results  of  analysis 
questionable. 


The  models  used  by  Thayer,  et  al ,  for  evaluation  of  error  data  are 
the  well  documented  models  of  Shooman,  Jelfnski  and  Moranda,  and  Schick.  The 
analysis,  though  interesting  and  well  done  is  not  applicable  to  pre-test  data 
collection  and  evaluation.  Therefore,  the  use  of  Thayer's  reliability 
estimates  is  very  limited. 

9.0  MYERS'  EXTENSION  TO  McCABE'S  CYCLOMATIC  COMPLEXITY 

Myers  reported  (SIGPLAN  1977)  on  an  anomaly  that  occurs  when  using 
different  techniques  to  determine  McCabe's  cyclomatic  complexity.  The  problem 
arises  since  there  are  two  ways  of  drawing  flow  diagrams  for  compound  IF 
statements.  The  following  example  is  used  to  illustrate  Myers'  concern: 

A)  IF  (X.EQ.O.)  THEN 
ELSE 

tl)  IF  (X.EQ.O.. AND. Y.GT.O.)  THEN 

ELSE 

C)  IF  (X.EQ.O.)  THEN 

IF  (Y.GT.O.)  THEN 
ELSE 

The  hypothesis  is  that  A  is  less  complex  then  B  and  that  B  is  Tess 
complex  than  C. 

If  McCabe's  cyclomatic  complexity  V(G)  is  computed  by  diagramming 
statements  or  counting  whole  predicates  as  decisions,  one  gets 


V( A)  =  2  <  V ( B )  =  2  <  V(C)  =  3 
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Similarly,  if  one  computes  V(G)  by  counting  individual  conditions  (plus  one), 
then 


V(A)  =  2  <  V ( B )  =  3  <  V { C )  =  3 

Neither  inequality  agrees  precisely  with  the  hypothesis,  so  Myers  suggested 
combining  the  calculations  and  displaying  a  complexity  interval.  Such  that, 

V ( A)  =  (2,2)  <  V ( B )  =  (2,3)  <  V(C)  =  (3,3) 

While  this  is  mathematically  appealing,  it  doesn't  appear  to  be  essential  for 
determining  module  complexity. 

However,  the  complexity  interval  is  easy  to  calculate,  provides  in¬ 
formation  regarding  programming  technique  (maintainability),  and  eliminates 
continually  justifying  the  computational  choice  of  V ( G ) .  Therefore,  it  is  re¬ 
commended  that  software  analysis  tools  be  extended  to  include  this. 

15 

It  should  be  noted  that  since  Halstead's  technique  (Section  3)  is 
based  on  use  of  operators  and  operands,  the  above  anomaly  is  handled  without 
amb i gu i ty . 
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10.0 


COMPARISON  O'7  HALSTEAD'S,  McCABE'S,  AND  KNOTS  METRICS 


The  McCabe  and  knots  metrics  are  based  on  program  control  flow. 
Neither  approach  penalizes  for  in-line  code  complexity.  McCabe's  complexity 
is  based  on  graph  theory  for  determination  of  nodes  and  paths.  These  flow 
graphs  are  mathematically  consistent  and  are  more  defensible  for  test  support. 
Knots  supports  the  determination  of  "unstructuredness1*  quite  well  and,  there¬ 
fore,  extends  McCabe's  cyclomatic  complexity.  However,  McCabe's  "Essential 
Complexity"  which  determines  subgraphs  also  addresses  the  issue  of  structured 
programming.  Another  advantage  of  McCabe's  over  knots  is  that  McCabe's 
metrics  can  be  determined  without  needing  the  actual  module  code.  Cyclomatic 
complexity  may  be  determined  from  directed  flow  graphs  and  Program  Design 
Languages  (PDLs). 

Halstead's  software  science  is  based  on  psychological  principles  of 
programmer  performance.  This  approach  extends  software  engineering  to  the 
principles  of  experimental  science.  It  is  not  based  on  control  flow  theory 
but  rather  the  number  of  unique  operators  and  operands  and  the  total  use  of 
each.  Therefore,  Halstead  does  address  the  issues  of  in-line  code  complexity. 
Software  science  handles  program  flow  by  investigating  the  code  for  the 
inclusion  of  decision  and  branching  statements. 

One  approach  to  studying  the  worth  of  metrics  for  flow  complexity 
issues  is  to  investigate  each  with  respect  to  accepted  methods  of  flow 
simplification.  Three  such  methods  are  1)  Linearization;  2)  Node  Splitting; 
and  3)  Structuring  Multiple  Exit  Loops, 

The  main  issue  of  1 inearization  is  that  the  same  two  dimensional  flow 
graph  as  shown  in  Figure  10-1  may  be  represented  by  different  code  (lineari¬ 
zation). 


A 


SAME  GRAPH  =>  DIFFERENT  CODE 

Figure  10- 1 .  Two  Dimensional  Flow-Graph 


The  code  produced  in  different  programs  may  have  the  same  flow  graph 
but  may  vary  in  complexity.  McCabe’s  complexity  metric  will  not  show  this 
difference  but  Halstead's  will.  Knots  measure  will  depend  on  the  particular 
1  inearization  (Figure  5-3)  and  also  on  the  implementation  language  (IF-THEN- 
ELSE  constructs)  . 

Node  splitting  refers  to  the  process  of  producing  an  executional  ly 
equivalent  flow  graph  G'  from  a  flow  graph  G,  where  one  node  in  G  appears  more 
than  once  in  G'.  In  many  instances,  such  transformations  may  be  used  to 
produce  flow  graphs  in  which  each  subgraph  consists  of  a  single  entry  arc  and 
a  single  exit  arc  (i.e.  structured  flow  graphs).  Figure  10-2  is  a  simple 
illustration  of  node  splitting  where  node  D  is  repeated  in  (b). 


Figure  10-2.  Mode  Splitting 


Since  node  splitting  involves  code  duplication,  Halstead's  V  (and 
hence  £)  increase  while  node  splitting  is  making  the  control  flow  less 
complex.  However,  this  may  lead  to  creation  of  subroutines  so  that  Halstead’s 
may  not  be  effected  greatly.  McCabe's  cyclomatic  complexity  is  not  adversely 
affected  by  the  duplication  of  code. 


One  flow  graph  construct  which  cannot  be  structured  using  only  node 
splitting  transformations  is  that  of  a  loop  with  different  patns  from  the  loop 
body  to  the  exit  node.  There  are  two  general  approaches  for  structuring  such 

flow  graphs  and  both  must  involve  the  use  of  additional  program  variables  to 

"remember"  key  program  variable  values  at  "critical  points"  in  the  execution 
of  the  loop  body.  These  values  can  then  be  used  to  determine  the  paths 

through  the  loop  and  allow  for  a  single  exit.  A  second  approach  involves  the 

use  of  Boolean  variables. 


In  the  subsequent  analyses  the  restrictive  notion  of  "multiple  exit 
loop"  in  Figure  10-3  serves  as  the  basis  for  discussion.  This  case  actually 
occurs  in  instances  of  multiple  error  exits  from  a  loop.  The  structured  flow 
graph  in  Figure  10-3  makes  use  of  the  Boolean  variable  'check1  to  predicate 
the  iteration. 


Figure  10-3.  Multiple  Exits 

Here  again,  the  suggested  solutions  for  handling  multiple  exits 
involves  increasing  the  amount  of  code  which  increases  Halstead's  metrics. 

In  the  case  of  structuring  multiple  exit  loops,  there  is  a  small 

increase  in  control  flow  (McCabe's)  complexity.  In  particular  the  increase  is 
fixed  at  a  small  level  and  is  not  unreasonable.  However,  the  increase  in 

software  effort  may  be  quite  large. 

With  respect  to  any  structuring  transformation.  Knots  metric 
indicates  that  such  trans forma tions  are  advisable.  This  follows  from  the  fact 
that  programs  which  are  well  structured  (in  the  sense  that  they  are  composed 
using  only  IF ...  THEN. .  .ELSE  and  DO  WHILE  control  flow  operators)  will  have 

X-0.  Thus,  any  set  of  transformations  which  structure  a  program  must  result 

in  a  program  with  a  K  value  no  grea'.er  than  that  of  the  original  program. 
Given  the  rather  intense  level  of  debate  concerning  the  utility  of  such 
t ran s f orma t i ons  ,  this  result  should  evoke  some  skepticism  of  the  knots 
measure. 
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Supporting  evidence  has  shown  that  Halstead's  metrics  support  the 
linearization  issue  quite  well,  node  splitting  somewhat,  and  multiple  exit 
loops  not  very  well.  McCabe's  on  the  other  hand  does  not  support  lineariz¬ 
ation  well  but  does  support  the  other  two  issues.  Arguments  can  be  made 
against  knots  in  all  three  issues.  It  may,  therefore,  be  concluded  that 
Halstead  and  McCabe  may  complement  each  other  in  resolution  of  the  above 
issues. 


A  further  observation  about  knots  is  that  programs  with  arbitrary 
amounts  of  structured  transfers  will  have  the  same  complexity  as  any  straight 
line  code.  This  is  not  the  case  for  Halstead  or  McCabe.  Knots,  however,  is 
the  best  measure  of  the  occurrence  of  "spaghetti"  code.  This  is  of  increas¬ 
ingly  less  value  with  the  increase  and  proliferation  of  languages  with 
structured  constructs. 
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CONCLUSIONS  AND  RECOMMENDATIONS 


Quantitative  measures  of  software  quality  are  still  in  their  infancy. 
Halstead's  software  science  end  McCabe's  cyclomatic  complexity,  currently  the 
best  developed  software  metrics,  show  promise  as  predictors  for  effort 
estimation,  testing,  reliability,  and  maintenance.  Woodward's  "knots"  control 
complexity  best  evaluates  structured  programming  constructs  and  augments 
McCabe's  cyclomatic  complexity. 

Recent  literature  has  pointed  out  weaknesses  and  limitations  of  each 
of  these  metrics  in  specific  situations  without  offering  viable  alternatives. 
The  lack  of  vast  empirical  data  to  evaluate/substantiate  proposed  metrics  has 
hindered  the  development  and  acceptance  in  software  engineering.  With  time, 
reliable  and  useful  standard  measuring  concepts  will  emerge. 

Thp  metrics  of  Halstead  and  McCabe  should  be  included  for  software 
evaluation.  McCabe's  cyclomatic  complexity  has  been  used  with  some  success. 
This  technique  should  be  expanded  to  also  determine  "essential"  complexity  to 
evaluate  structured  programming  constructs.  If  this  is  done,  there  will  be 
minimal  additional  value  obtained  by  Woodward's  "knots"  metric  and,  therefore, 
"knots"  need  not  be  included.  Halstead's  and  McCabe's  metrics,  especially 
utilized  in  concert,  can  help  to  assess  the  testability  and  maintainability  of 
software  to  be  imolemented.  The  information  required  to  determine  these 
metrics  will  undoubtedly  be  necessary  for  or  similar  to  information  required 
for  other  metrics  that  may  be  proposed  in  the  future. 

In  summary,  the  metrics  presented  here  to  assess  software  quality 
should  be  included  in  a  software  assessment  tool.  They  are  only  partially 
validated  and,  therefore,  must  be  used  with  some  care.  They  are  intended  to 
quantify  information  that  is  extremely,  subjective.  Software  type,  programming 
language,  timing  constraints,  and  coding  efficiency  should  always  be  con¬ 
sidered  when  assessing  software.  However,  these  metrics,  especially  if  used 
together,  will  help  determine  modules  that  are  overly  complex,  difficult  to 
test/maintain,  potentially  error  prone,  in  need  of  rework,  and  possibly 
catastrophic  to  the  system  under  test. 
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1.0 


INTRODUCE  .  ! 


This  report  discusses  the  strength  (cohesion)  and  interconnectivity 
(coupling)  of  modules  and  provides  recommendations  for  assessment  of  software 
as  a  total  system. 

Unfortunately,  there  are  no  currently  existing  automated  techniques 
to  determine  module  cohesion  or  coupling.  However,  this  report  will  discuss 
the  various  aspects  and  terminology  applied  to  modularity,  strength,  and 
coupling.  It  is  recommended  that  this  terminology  be  adopted  for  use  in 
software  assessment.  A  technique  to  determine  the  relative  strengths  and 
coupling  of  modules  is .  presented.  Furthermore,  system  level  metrics  are 
summarized  for  potential  application  in  future  test  efforts. 
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2.0. 


SOFTWARE  STRUCTURE 


Software  structure  is  a  hierarchical  representation  which  indicates 
the  relationship  between  elements  (called  modules)  in  a  software  solution  to 
a  problem  implicitly  defined  by  requirements  analysis.  The  evolution  of 
software  structure  begins  with  the  problem  definition.  Parts  of  the  problem 
are  solved  by  one  or  more  software  elements  (modules).  This  process  is 
symbolically  shown  in  Figure  1  where  modules  are  created  to  solve  different 
parts  of  the  problem. 


Figure  1.  Evolution  of  Software  Structure 
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Software  structure  represents  a  program  architecture  that  implies  a 
hierarchy  of  control.  However,  the  procedural  aspects  of  software  are  not 
represented  by  structure.  For  instance,  structure  does  not  represent  the 
sequence  of  processes,  the  repetition  of  operations,  or  the  occurrance  and 
order  of  decisions. 

The  structure  of  a  software  system  may  be  created  by  utilizing  and 
interfacing  modules  in  different  ways.  All  modules  could  communicate  dir¬ 
ectly  with  a  single  "controlling"  module.  This  design  would  require  all  data 
elements  to  be  defined  by  the  controlling  module  and  “ping-pong"  in  and  out 
as  required.  Furthermore,  the  controlling  module  will  become  extremely  large 
and  complex  for  all  but  simple  problems.  Software  systems  should  be  factored 
to  consolidate  flow  of  control  and  decision  making  modules. 

By  distributing  control  in  a  top-down  fashion,  design  and  imple¬ 
mentation  are  simpified,  testability  is  enhanced,  and  maintenance  can  be 
■  •  approached  in  a  more  efficient  manner. 

It  can  be  seen  from  Figure  Z  that  a  problem  may  be  solved  by  many 
different  software  structures.  Because  each  is  based  on  different  philo¬ 
sophies,  each  design  method  will  result  in  a  different  structure  for  the  same 
set  of  software  requirements.  Unfortunately,  there  is  no  magic  formula  to 
determine  "which  is  best".  However,  there  are  characteristics  of  a  structure 
that  can  be  examined  and  should  be  considered  when  assessing  software.  These 
design  methodologies  are  discussed  below  and  should  be  considered  during 
software  assessment. 
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2.1  Structural  Definitions 

•  In  order  to  facilitate  discussions  on  software  structure  and 

recommended  metrics,  a  few  simple  measures  and  terms  are  defined.  Each  of 
the  boxes  contained  in  a  structure  diagram  represents  one  modul e  —  a  sep¬ 
arately  addressable  element  of  a  program  (e.g.,  subroutine,  function,  pro- 
I  cedure) .  Figure  3  illustrates  various  measures  of  structure.  Depth  refers 

to  the  number  of  layers  of  control  (vertically)  and  width  refers  to  the 
overall  span  of  control  (horizontally).  Fan-out  is  a  measure  of  the  number 
of  modules  that  are  directly  controlled  by  another  module.  While  fan-i n 
I  _  indicates  how  many  modules  directly  control  a  given  module. 


I 
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Figure  3.  Measures  of  Structure 

The  control  relationship  among  modules  may  be  expressed  in  the 
following  way.  A  module  that  controls  another  module  is  said  to  be  super¬ 
ordinate  to  it.  Conversely,  a  module  controlled  by  another  is  said  to  be 
subordinate  to  the  controller.  For  example,  in  Figure  3,  module  A  is  super¬ 
ordinate  to  modules  B,  C,  and  D  and  ultimately  superordinate  to  all  modules 
in  the  system.  Module  K  is  directly  subordinate  to  modules  E  and  F  and 
ultimately  subordinate  to  modules  B  and  A.  The  depth  of  module  B  is  3  and 
the  width  of  module  I  is  5. 
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3.0 


MODULARITY 


The  concept  of  modularity  in  computer  software  has  been  espoused  for 
two  decades.  Myers  has  stated  that  "modularity  is  the  single  attribute  of 
software  that  allows  a  program  to  be  intellectually  manageable".  Monolitic 
software  (i.e.,  a  large  program  comprised  of  a  single  module)  cannot  be 
easily  understood.  The  number  of  control  paths,  span  of  reference,  number  of 
variables,  and  overall  complexity  would  make  maintainability  extremely 
difficult. 

It  has  been  shown  in  literature  that  partitioning  a  software  sol¬ 
ution  into  modules  increases  understanding  and  greatly  enhances  maintain¬ 
ability.  It  is  easier  to  solve  a  complex  problem  if  it  is  reduced  to  man¬ 
ageable  pieces.  However,  this  can  be  carried  only  so  far.  Other  factors 
besides  module  size  must  be  considered  when  developing  software.  As  software 
is  partitioned  into  modules,  the  requirements  to  interface  information  among 
the  modules  increases.  We  cannot  simply  make  modules  smaller  and  smaller  and 
expect  the  total  system  complexity  to  decrease.  When  assessing  software  at 
USAEP6,  the  concepts  of  module  cohesion  (strength)  and  coupling  must  be 
considered.  These  concepts  are  described  in  Section  4  of  this  report. 

Given  the  same  set  of  requirements,  the  greater  number  of  modules 
means  a  smaller  module  size  and,  therefore,  less  cost  and  effort  to  create 
and  maintain  each  module.  However,  as  noted  above,  the  requirements  to 
interface  the  modules  increases.  Figure  4  illustrates  the  relationship 
between  modularity  and  software  cost  or  effort  (development  or  maintenance) . 

There  is  a  number  of  modules  somewhere  in  the  region  between  Mi  and  M2  that 
would  result  in  minimum  effort.  However,  we  do  not  currently  have  the 

necessary  sophistication  to  predict  what  this  number  should  be. 


TOTAL  COST 


NUMBER  OF  MODULES 

Figure  4.  Modularity  and  Software  Cost 

In  the  sections  that  follow,  some  guidelines  are  presented  to  help 
determine  how  software  should  be  modularized.  However,  before  discussing 
coupling  and  cohesion,  the  concepts  of  abstraction,  information  hiding,  and 
module  type  are  presented. 

3.1  Abstraction 

When  a  modular  solution  to  a  problem  is  considered,  many  levels  of 
abstraction  can  be  posed.  At  the  highest  level  of  abstraction,  a  solution  is 
stated  in  broad  terms,  using  the  language  of  the  problem  environment.  At 
lower  levels  of  abstraction,  a  more  procedural  orientation  is  taken. 
Problem-oriented  terminology  is  coupled  with  implementation-oriented  term¬ 
inology  in  an  effort  to  state  a  solution.  Finally,  at  the  lowest  level  of 
abstraction,  the  solution  is  stated  in  a  manner  that  can  be  directly  im¬ 
plemented. 
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Each  step  in  the  software  engineering  process  is  a  refinement  in  the 
level  of  abstraction  of  the  software  solution.  During  system  definition, 
software  is  described  as  a  complete  system  element  in  the  context  of  the 
entire  system.  During  software  planning  and  requirements  analysis,  the 
software  solution  is  stated  in  terms  "that  are  familiar  in  the  problem  en¬ 
vironment."  As  we  move  from  preliminary  to  detailed  design,  the  level  of 
abstraction  is  reduced.  Finally,  the  lowest  level  of  abstraction  is  reached 
when  source  code  is  generated. 

The  concepts  of  stepwise  refinement  and  modularity  are  closely 
aligned  with  abstraction.  As  the  software  design  evolves,  each  level  of 
modules  in  software  structure  represents  a  refinement  in  the  level  of  ab¬ 
straction  of  the  software.  In  reality,  a  factored  (Section  2)  structure 
distributes  levels  of  control  and  decision  making,  that  is,  levels  of  ab¬ 
straction. 

3.2  Information  Hiding 

The  principle  of  information  hiding  suggests  that  modules  be 
"characterized  by  design  decisions  that  each  hides  from  all  others."  In 
other  words,  modules  should  be  specified  and  designed  so  that  information 
(procedure  and  data)  contained  within  a  module  are  inaccessible  to  other 
modules  that  have  no  need  for  such  information. 

The  term  "hiding"  implies  that  effective  modularity  can  be  achieved 
by  defining  a  set  of  independent  modules  that  communicate  with  one  another 
only  that  information  that  is  necessary  to  achieve  software  function.  Ab¬ 
straction  helps  to  define  the  procedural  (or  informational)  entities  that 
comprise  the  software.  Hiding  defines  and  enforces  access  constraints  to 
both  procedural  detail  within  a  module  and  any  local  data  structure  used  by 
the  module. 
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The  use  of  information  hiding  as  a  design  criteria  for  modular 
systems  provides  greatest  benefits  when  modifications  are  required  during 
testing  and  later,  during  software  maintenance.  Because  most  data  and  pro¬ 
cedure  are  “hidden"  from  other  parts  of  the  software,  inadvertent  errors 
introduced  during  modification  are  less  likely  to  propagate  to  other  loca¬ 
tions  within  the  software. 

3.3  Module  Types 

Abstraction  and  information  hiding  are  used  to  define  modules  within 
a  software  structure.  Both  of  these  attributes  must  be  translated  into 
module  operational  features  that  are  characterized  by  time  history  of  in¬ 
corporation,  activation  mechanism,  and  pattern  of  control. 

Time  history  of  incorporation  refers  to  the  time  at  which  a  module 
is  included  within  a  source  language  description  of  the  software.  For 
example,  a  module  defined  as  a  compile  time  macro  is  included  as  in-line  code 
by  the  compiler  when  an  appropriate  reference  is  made.  A  conventional 
subprogram  (e.g.,  a  subroutine  or  procedure)  is  included  through  generation 
of  branch  and  link  code. 

Two  activation  mechanisms  are  encountered.  Conventionally,  a  module 
is  invoked  by  reference  (e.g.,  a  "call"  statement).  However,  in  real-time 
applications,  a  module  may  be  invoked  by  interrupt;  that  is,  an  outside  event 
causes  a  discontinuity  in  processing  that  results  in  passage  of  control  to 
another  module.  Activation  mechanics  are  important  because  they  can  affect 
software  structure. 

The  pattern  of  control  of  a  module  describes  the  manner  in  which  it 
is  executed  Internally.  Conventional  modules  have  a  single  entry  and  exit 
and  are  executed  sequentially  as  part  of  one  user  task.  More  sophisticated 
patterns  of  control  are  sometimes  required.  For  example,  a  module  may  be 
reentrant.  That  is,  a  module  is  designed  so  that  it  does  not  in  any  way 
modify  itself  or  the  local  addresses  that  it  references.  Therefore,  the 
module  may  be  used  by  more  than  one  task  concurrently. 
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Within  a  software  structure,  a  mcdule  may  be  categorized  as: 

o  A  sequential  module  that  is  referenced  and  executed  without 
apparent  interruption  by  the  applications  software. 

o  An  incremental  module  that  can  be  interrupted  prior  to  com¬ 
pletion  by  applications  software  and  subsequently  restarted 
at  the  point  of  interruption. 

o  A  parallel  module  that  executes  simultaneously  with  another 
module  in  concurrent  mul ti processor  environments. 

Sequential  modules  are  most  commonly  encountered  and  are  char¬ 
acterized  by  compile  time  macros  and  conventional  subprograms  —  subroutines, 
functions,  or  procedures.  Incremental  modules,  often  called  coroutines, 
maintain  an  entry  pointer  that  allows  the  module  to  restart  at  the  point  of 
interruption.  Such  modules  are  extremely  useful  in  interrupt-driven  systems. 
Parallel  modules,  sometimes  called  conroutines,  are  encountered  when  high¬ 
speed  computation  (e.g.,  pipeline  processing)  demands  two  or  more  CPUs 
working  in  para lie*. 

A  typical  control  hierarchy  (a  factored  structure)  may  not  be  en¬ 
countered  when  coroutines  or  conroutines  are  used.  Such  nonhierarchical  or 
homologous  structures  require  special  design  approaches  that  are  in  early 
stages  of  development.  Software  assessment  should  include  information  with 
respect  to  atypical  structures. 
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4.0 


MODULE  INDEPENDENCE 


The  concept  of  module  independence  is  a  direct  outgrowth  of  mod¬ 
ularity  and  the  concepts  of  abstraction  and  information  hiding.  In  landmark 
papers  on  software  design,  Parnas  and  Wirth  allude  to  refinement  techniques 
that  enhance  module  independence.  Later  work  by  Stevens  et  al .  solidified 
the  concept. 

Module  independence  is  achieved  by  developing  modules  with  "single- 
minded"  functions  and  an  "aversion"  to  excessive  interaction  with  other 
modules.  Stated  another  way,  we  want  to  design  software  so  that  each  module 
addresses  a  specific  subfunction  of  requirements  and  has  a  simple  interface 
when  viewed  from  other  parts  of  the  software  structure. 

It  is  fair  to  ask  why  independence  is  important.  Software  with 
effective  modularity,  that  is,  independent  modules,  is  easier  to  develop 
because  function  may  be  compartmentalized  and  interfaces  are  simplified 
(consider  ramifications  when  development  is  conducted  by  a  team).  Indepen¬ 
dent  modules  are  easier  to  maintain  (and  test)  because  secondary  effects 
caused  by  design  and  code  modification  are  limited,  error  propagation  is 
reduced,  and  “plug-in"  modules  are  possible.  To  summarize,  module  indepen¬ 
dence  is  a  key  to  good  design,  and  design  is  the  key  to  software  quality  and 
software  quality  test  assessment. 

Independence  is  measured  using  two  qualitative  criteria:  cohesion 
and  coupling.  Cohesion  is  a  measure  of  the  relative  functional  strength  of  a 
module.  Coupling  is  a  measure  of  the  relative  interdependence  among  modules. 

4.1  Coup!  ing 

Coupling  is  defined  as  the  degree  of  interdependence  between  two 
modules.  The  better  the  system,  the  lower  its  coupling.  Coupling  is  con¬ 
cerned  with  how  two  modules  communicate  with  each  other  whether  it  be  by 
parameters,  a  global  data  area  or  by  referring  to  data  inside  of  the  other. 
Low  or  loose  coupling  means  that  no  module  has  to  worry  about  the  internal 
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workings  of  the  other  which  makes  for  simple  to  understand  systems.  In 
addition,  modules  with  low  coupling  have  fewer  connections  meaning  less 
chance  for  a  bug  in  one  module  appearing  as  a  symptom  in  another  (ripple 
effect).  They  also  minimize  the  risk  of  affecting  one  module  due  to  changing 
another. 

Five  different  types  of  coupling  may  occur  between  modules.  They 

are: 

1.  data  coupling 

2.  stamp  coupling 

3.  control  coupling 

4.  common  coupling 

5.  content  coupl ing 

Two  modules  may  be  coupled  by  me,  '  than  one  type  of  coupling  or  by 
the  same  type  a  number  of  times.  If  two  modules  are  coupled  in  more  than  one 
way,  their  coupling  is  defined  by  the  worst  (tightest)  coupling  they 
exhibit.  The  following  sections  describe  these  types. 

4.1.1  Data  Coupling 

Two  modules  are  data  coupled  if  they  communicate  by  parameters,  each 
parameter  being  a  single  variable,  constant,  or  homogeneous  table  (a  table  in 
which  each  entity  is  of  the  same  type).  All  that  is  passed  between  the 
modules  is  the  necessary  data  it  needs  to  carry  out  its  finction.  For 
example,  employee  salary  rate  would  not  be  passed  to  a  module  who's  function 
is  to  print  the  employee's  address  on  an  envelope.  This  type  of  coupling 
which  Is  unavoidable  and  perfectly  acceptable,  represents  the  most  desirable 
type  of  coupling.  Modules  A  and  C  of  Figure  5  are  examples  of  data  coupled 
modules. 
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DATA  COUPLING 


Figure  5.  Low  Coupling 


4.1.2  Stamp  Coupling 

A  group  of  modules  are  stamp  coupled  if  they  pass  a  composite  piece 
of  data  consisting  of  a  number  of  fields.  Data  structures  such  as  records 
are  a  good  way  of  cutting  down  on  excessive  data  coupling  as  long  as  all  the 
fields  have  meaning  for  all  modules  concerned.  However,  stamp  coupling 
should  be  avoided  where  possible  because  it  creates  unnecessary  connections 

between  modules.  Suppose  module  B  only  needs  a  few  fields  in  a  record.  By 

passing  the  entire  record,  B  is  forced  to  be  aware  of  the  entire  structure  of 
the  record  and  B's  chances  of  inadvertently  modifying  the  record  are  in¬ 
creased.  Figure  5  illustrates  stamp  coupling  between  modules  A  and  B. 

4.1.3  Control  Coupling 

When  one  module  passes  to  another,  a  piece  of  information  intended 

to  control  the  internal  logic  of  the  other,  they  are  said  to  be  control 

coupled.  This  piece  of  information  can  take  the  form  of  control  flag  or  can 
be  implied  in  a  piece  of  data.  This  type  of  coupling  is  undesirable  because 
the  calling  module  must  understand  the  logic  of  the  subordinate  module. 


-  -  -- . .  ■ 
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Thus,  an  overall  understanding  of  each  module  becomes  more  difficult. 
Another  undesirable  situation  that  a  passed  control  flag  indicates  is  that  a 
function  has  been  split  between  two  modules  which  should  in  fact  be  kept  in 
one. 


Figure  6.  Moderate  Coupling 


4.1.4  Common  Coupling 

Two  modules  are  common  coupled  if  they  reference  the  same  global 
data  area.  FORTRAN  modules  referencing  data  in  a  COWON  area  and  groups  of 
modules  referencing  data  in  an  absolute  storage  location  (including  regis¬ 
ters)  are  examples  of  common  coupling.  The  idea  of  modularity  is  degraded  by 
common  coupling  because  data  is  not  confined  to  a  single  module  or  at  most  a 
small  group  of  modules.  Some  problems  which  could  arise  because  of  common 
coupling  are: 


14 


A  bug  in  any  module  using  the  global  area  may  show  up  in  any 
other  module  using  the  global  area. 

Modules  using  global  data  areas  use  explicit  names  to  refer¬ 
ence  the  data,  hence  the  module  cannot  be  used  for  another 
application  in  which  the  variable  names  are  different. 

Modules  and  the  data  it  uses  become  more  difficult  to  under¬ 
stand. 

If  a  piece  of  data  or  its  structure  within  the  global  data 
area  changes  then  all  modules  which  reference  that  global  area 
must  be  modified  which  is  time  consuming  and,  hence,  less 
maintainable. 

It  should  be  noted  that  if  two  modules  are  common  coupled,  it  is 
not  necessary  that  one  module  cal',  the  other,  just  the  fact  that  the  two 
reference  the  same  data  area  is  enough  criteria  for  common  coupling  (see 
Figure  7) . 


MODULES  C,  F,  ANO  0  ARE  COMMON  COUPLED 
MOOULES  E  ANO  L  ARE  ALSO  COMMON  COUPLED 

Figure  7.  High  Coupling 
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4.1.5  Content  Coupling 


Content  coupling  pertains  mostly  to  assembly  language.  It  refers  to 
the  situation  In  which  one  module  directly  references  the  contents  of 
another.  For  instance,  if  module  A  somehow  references  data  in  module  B  by 
using  an  absolute  displacement,  the  modules  are  content  coupled.  Almost  any 
change  to  B,  or  maybe  just  recompiling  B  with  a  different  version  of  the 
compiler  will  Introduce  error  into  the  program.  Fortunately,  most  high  order 
languages  offer  no  way  to  implement  content  coupling. 

4.1.6  Determining  Coupling  Type 

Data  coupling  between  a  calling  and  called  module  is  recognized  when 
the  parameters  of  the  call  contain  only  simple  data  types  or  homogeneous 
tables.  Stamp  coupling  is  recognized  when  one  or  more  parameters  is  a  non- 
homogeneous  composite  piece  of  data  such  as  a  record.  If  one  or  more  of  the 
parameters  passed  is  used  in  a  condition  statement  within  the  called  module, 
the  two  modules  are  control  coupled.  Common  coupling  can  be  detected  by 
modules  according  to  the  global  data  areas  they  reference.  The  modules 
within  each  group  are  common  coupled.  If  a  module  contains  a  branch  to  a 
label  which  is  not  defined  in  the  scope  of  the  module  Itself,  it  is  content 
coupled  with  the  module  in  which  the  label  is  defined. 

Automatic  determination  of  module  coupling  by  a  static  analyzer  can 
be  achieved  by  examining  data  flow  between  modules  and  applying  the  above 
criteria  to  categorize  the  coupling  type. 

4.1.7  Summary  of  Coupling 

The  following  Is  a  table  which  summarizes  each  type  of  coupling  and 
their  specific  qualities. 
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COUPLING  TYPE 

SUSCEPTIBILITY 

TO  RIPPLE 

EFFECT 

MOO  I  F  I  - 

ABILITY 

UNDER - 

STANDAB ILITY 

MOOULE’S 

USABILITY  IN 

OTHER  SYSTEMS 

Data 

Variable 

Good 

Good 

Good 

Stamp 

Variable 

Medium 

Medium 

Medium 

Control 

Medium 

Poor 

Poor 

Poor 

Common 

Poor 

Medi urn 

Bad 

Bad 

Content 

Bad 

Bad 

Bad 

Bad 

4.2  Cohesion 

Modules  are  made  up  of  elements  --  pieces  of  code  which  accomplish  some 
task.  An  instruction,  a  group  of  instructions,  or  a  call  to  another  module  are 
such  elements.  Cohesion  is  a  measure  of  the  strength  of  functional  associations 
of  the  elements  within  a  module  and  therefore  is  synonymous  with  module  stren¬ 
gth.  Strong,  highly  cohesive  modules  contain  elements  which  are  genuinely 
4*  related.  Their  independence  from  information  in  other  unrelated  modules  and 

their  unity  make  for  low  coupling  and  easily  maintained  modules. 


There  are  seven  different  degrees  of  cohesion  which  will  be  discussed  in  sub¬ 
sequent  sections.  These  are  in  order  of  strength:  functional,  sequential, 
communicational ,  procedural,  temporal,  logical,  and  coincidental.  The  first 
three,  functional,  sequential,  and  communicational  represent  the  most  easily 
maintained  modules,  while  the  lower  levels  of  cohesion,  procedural ,  temporal, 
logical  and  coincidental  are  less  easily  maintained. 


Type 

Functional 

Sequential 

Communicational 


SCALE  OF  COHESION 

Maintainabil ity 
Best 

I 

Worst 


Segmentation 

Black  box 

Not-quite-so- 
black  box 

Gray  box 

White  or 
transparent  box 


Procedural 

Temporal 

Logical 

Coincidental 
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4.2.1  Functional  Cohesion 


Those  modules  which  are  functionally  cohesive  are  the  most  easily 
maintained  modules  and  have  the  lowest  coupling.  They  contain  elements  which 
all  contribute  to  one  and  only  one  problem- related  task.  The  module  may  call 
other  modules  in  order  to  solve  subproblems  of  the  main  task  and  these  may  in 
turn  call  other  modules,  but  the  calling  module  is  still  considered  function¬ 
ally  cohesive  as  long  as  it  accomplishes  one  problem-related  function. 
"Calculate  Net  Employee  Salary"  is  an  example  of  one  such  module  with 
"Calculate  FICA  Deductions"  a  subfunction  which  it  calls. 

4.2.2  Sequential  Cohesion 

The  second  most  cohesive  module  is  one  that  is  sequentially  cohes¬ 
ive.  Its  elements  are  involved  in  activities  which  are  carried  out  in  a 
specific  order  so  that  the  result  of  one  is  the  input  data  for  the  next. 
"Format  and  Cross-Val idate  Record"  which  has  three  activities,  "format  raw 
record",  "crossval idate  fields  in  record",  and  "print  error  or  confirmation 
message",  is  an  example  of  a  sequentially  cohesive  module.  Each  activity 
depends  on  the  result  of  the  previous  activity.  Like  the  functionally  co¬ 
hesive  module,  this  type  also  has  low  coupling  but  unlike  the  former,  its 
activities  cannot  be  summed  up  as  a  single  independent  function  and  therefore 
is  not  as  easily  reusable  by  other  programs. 

4.2.3  Communicational  Cohesion 

A  communicationally  cohesive  module  is  one  whose  elements  make  up 
activities  which  use  the  same  data.  Like  sequential  cohesion,  its  activities 
cannot  be  summed  up  as  one  problem-solving  function.  In  contrast  to  sequen¬ 
tially  cohenslve  modules  however,  execution  of  communicationally  cohesive 
modules  activities  do  not  have  to  be  carried  out  in  a  specific  order.  These 
modules  also  maintain  clean  coupling  but  ease  of  maintainability  is  lost 
because  attempting  to  modify  one  activity  will  usually  affect  another  erron¬ 
eously.  Also  if  only  one  activity  is  really  needed,  a  call  to  the  communi¬ 
cationally  cohesive  module  will  result  in  unnecessary  production  of  data 
and/or  execution  of  code. 
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4.2.4  Procedural  Cohesion 


Previous  to  this  level  of  cohesion,  a  module's  activities  were 
strongly  related  to  data.  As  we  cross  the  boundary  from  easily  maintainable 
modules  to  the  less  easily  maintainable  with  procedural  cohesion,  it  is 
control,  not  data,  that  flows  from  one  activity  to  the  next.  A  procedura'lly 
cohesive  module  contains  elements  which  are  involved  with  different  and 
possibly  unrelated  activities.  They  are  placed  in  one  module  because,  al¬ 
though  they  may  be  unrelated,  they  must  be  carried  out  in  some  specific 
order. 

An  example  is  a  module  called  "NEWTRAN'  which  contains  two  activities  — 
"update  record  on  file"  and  "get  next  transaction".  Usually  much  data  must 
be  passed  to  these  types  of  modules  leading  to  poor  coupling. 

4.2.5  Temporal  Cohesion 

These  modules  have  elements  which  are  involved  with  activities  that 
are  related  in  time.  Temporal  cohesion  is  similar  to  communicational  co¬ 
hesion  except  that  each  activity  must  be  carried  out  at  the  same  time  instead 
of  on  the  same  data.  It  is  different  from  procedural  cohesion  because  exe¬ 
cution  order  is  unimportant.  The  classic  example  of  such  a  module  is  an 
initialization  module.  Coupling  is  fairly  poor  and  the  module  is  not  easily 
reused. 

4.2.6  Logical  Cohesion 

A  logically  cohesive  module  contains  elements  that  contribute  to 
activities  of  the  same  general  category.  This  type  of  cohesion  differs  from 
the  previously  defined  types  because  not  all  of  its  activities  will  neces¬ 
sarily  be  carried  out.  The  input  data  to  the  module  determines  execution 
which  leads  to  tight  coupling  and  possibly  unused  parameters. 

Not  only  does  this  type  of  cohesion  make  for  code  which  is  difficult 
to  understand,  it  also  violates  the  principle  of  Independent  modules  since  an 
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outside  source  controls  the  inner  workings  of  the  module.  An  example  of  such 
a  module  is  one  which  produces  either  a  sales  report,  a  project  status  re¬ 
port,  or  a  customer  transaction  report,  depending  on  whether  the  parameter 
flag  is  1,  2  or  3. 

4.2.7  Coincidental  Cohesion 

Coincidental  cohesion  is  similar  to  logical  cohesion  except  that  the 
activities  of  a  coincidentally  cohesive  module  do  not  even  belong  to  a  simi¬ 
lar  category  as  in  logically  cohesive  modules.  Organization  is  not  based  on 
either  control  or  data  flow  but  is  dependent  on  an  input  flag  to  tell  them 
what  to  do,  similar  to  logical  cohesion.  It  does  not  carry  out  one  well- 
defined  function  and  is  difficult  to  understand.  Such  modules  are  rare  and 
represent  the  lowest  level  of  cohesion  possible. 

4.2.8  Determining  Module  Cohesion 

Figure  8  depicts  a  decision  tree  which  deterines  the  level  of  co¬ 
hesion  of  a  module.  By  answering  the  questions  and  following  the  paths 
indicated,  one  will  eventually  arrive  at  the  level  of  cohesion  for  that 
module. 

4.2.9  Summary  of  Cohesion 


The  following  table  presents  a  summary  of  the  specific  qualities  of 
each  type  of  cohesion. 


COHESION  LEVEL 

COUPLING 

CLEANLINESS 

OF  1 MPLE • 

MENTATION 

USABILITY 

IN  OTHER 

PROGRAMS 

MOO  1  FI  - 

ABILITY 

understand  - 

ABILITY 

Functional 

Good 

Good 

Good 

Good 

Good 

Sequential 

Good 

Good 

Medium 

Good 

Good 

Communicational 

Medium 

Good 

Poor 

Medium 

Medium 

Procedural 

Variable 

Medium 

Poor 

Variable 

Variable 

Temporal 

Poor 

Medium 

Bad 

Medium 

Medium 

Logical 

Bad 

Bad 

Bad 

Bad 

Poor 

Coincidental 

Bad 

Bad 

Bad 

Bad 

Bad 
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MODULE  DOING 
ONE  PROBLEM  - 
RELATED  FUNCTION 


WHAT  RELATES 
ACTIVITIES  WITHIN 
MODULE? 


CONTROL  FLOW' 


NEITHER 


SEQUENCE 

IMPORTANT? 


SEQUENCE 

IMPORTANT? 


ARE  ACTIVITIES 
SIMILAR? 


FUNCTIONAL  SEQUENTIAL  COMMUNICATIONAL  PROCEDURAL  TEMPORAL  LOGICAL  COINCIDENTAL 


HIGH . 

COHESION 

SPECTRUM 

MORE  EASILY  MAINTAINED 

LESS  EASILY  MAINTAINED 
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REDUCTION  OF  PROGRAM  COMPLEXITY: 
MCCABE'S  ESSENTIAL  COMPLEXITY 


1.0  INTRODUCTION 

The  complexity  of  the  control  structure  of  a  module  gives  a  good 
measurement  of  the  complexity  of  the  module.  The  control  structure  itself 
can  be  represented  by  its  flow  graph.  Thus,  by  studying  the  flow  graph,  one 
can  obtain  the  complexity  measure  of  the  module.  This  is  the  approach  used 
by  McCabe  to  compute  program  complexity  as  reported  in  the  IEEE  Transactions 
on  Software  Engineering,  SE-2 ( 4 }  1976.  This  is  referred  to  as  the  cyclomatic 
complexity  of  the  module. 

Oftentimes,  the  complexity  of  a  program  can  be  reduced  by  parti¬ 
tioning  off  appropriate  portions  of  the  program  as  subroutines  or  sub¬ 
procedures.  These  portions  correspond  to  the  'removable'  subgraphs  of  the 
flow  graph.  Condensing  each  of  these  removable  subgraphs  into  a  single  node 
reduces  the  graph  into  a  simpler  graph.  McCabe  defined  the  complexity  of  the 
reduced  graph  as  the  essential  complexity  of  the  program.  It  is  the  purpose 
of  this  report  to  present  algorithms  for  identifying  removable  subgraphs  of  a 
flow  graph  and  describe  a  method  to  compute  McCabe's  essential  complexity. 

The  issue  of  identifying  removable  subgraphs  is  discussed  below. 
First,  an  overview  of  the  approach  is  presented.  Secondly,  the  recommended 
method  for  determining  the  subgraphs  is  discussed  in  detail.  Finally,  a  high 
level  Program  Design  Language  representation  of  the  algorithm  is  presented. 
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2.0 


OVERVIEW  OF  THE  APPROACH 


The  removable  subgraphs  can  be  determined  by  successive  elimination. 
First,  a  coarse  criterion  is  used  to  find  all  subgraphs  that  are  likely 
candidates  for  removal,  and  then  apply  a  series  of  discriminatory  criteria  to 
rule  out  subgraphs  that  are  not  truly  removable.  The  following  is  a  summary 
of  the  procedure.  An  example  is  given  at  the  end  to  illustrate  the  pro¬ 
cedure: 


Step  1.  Every  removable  subgraph  has  a  unique  entry  node  and 
a  unique  exit  node.  The  first  step  is  to  search  through  the 
flow  graph  to  find  all  pairs  of  nodes  that  might  constitute  the 
entry  node  and  the  exit  node  of  a  removable  subgraph.  This  is 
done  by  examining  the  dominator  tree  and  the  subordinate  tree 
of  the  flow  graph.  The  concept  of  dominator  and  subordinate  is 
discussed  in  detail  in  Section  3. 

Step  2.  For  each  pair  found  in  Step  1,  determine  the  subgraph 
between  the  two  nodes.  The  subgraph  consists  of  nodes  that  are 
dominated  by  the  entry  node  and  have  the  exit  node  as  a  sub¬ 
ordinate.  Discard  all  subgraphs  consisting  of  a  single  node. 

The  next  3  steps  eliminate  subgraphs  with  illegal  branches.  More¬ 
over,  Step  1  above  rules  out  the  following  cases:  branching  out  of  the  sub¬ 
graph  to  a  node  that  is  not  an  ancestor  of  the  entry  node,  and  branching  into 
the  subgraph  from  a  node  that  is  not  a  descendant  of  the  exit  node  from 
consideration. 

Step  3.  If  the  subgraph  branches  at  the  exit  node  to  more  than 
one  outside  node,  eliminate  the  subgraph  from  consideration. 

Step  4.  Eliminate  the  subgraph  if  it  can  be  entered  from  a 
descendant  node  of  the  exit  node.  This  step  takes  care  of 
backward  branching  into  the  subgraph. 
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Step  5.  Eliminate  the  subgraph  if  there  is  an  exit  from  the 
subgraph  to  an  ancestor  node  of  the  entry  node.  This  step 
takes  care  of  backward  branching  out  of  the  subgraph. 

Step  6.  Compute  the  reduced  complexity  measure.  Let  v  be  the 
complexity  measure  of  the  original  flow  graph.  Suppose  a  re¬ 
movable  subgraph  is  replaced  by  a  node,  then  the  complexity  v 
is  reduced  by  (e  -  n  +  1),  where  n  is  the  number  of  the  nodes 
in  the  subgraph  and  e  is  the  number  of  edges.  In  other  words, 
if  red_v  is  the  reduced  complexity,  then 

red  v=v-(e-n+l). 


The  flow  graph  shown  in  Figure  1  is  used  to  illustrate  the  above  procedure. 
This  graph  has  9  nodes,  with  node  1  as  the  initial  node  and  node  9  as  the 
terminal  node. 


Applying  Step  1  to  the  above  example  produces  the  following  pairs  of 
nodes:  (1,2),  (1,3),  (2,3),  (2,9),  (3,9)  and  (5,8).  In  addition,  all  pairs  of 
the  form  (n,n)  are  also  produced  (it  is  possible  that  the  entry  node  and  exit 
node  coincide,  for  example,  a  loop). 

At  Step  2,  following  subgraphs  are  produced:  (<a,b>  denotes  the 
subgraph  between  node  a  and  node  b.) 


<1 ,2>  :  nodes  1  and  2 

<1,3>  :  nodes  1,  2  and  3 

<2,3>  :  nodes  2  and  3 

<2,9>  :  nodes  2,  3,  4,  5,  6,  7,  8  and  9 

<3,9>  :  nodes  3,  4,  5,  6,  7,  8  and  9 

<5,8>  :  nodes  5,6,7  and  8 


Subgraphs  of  the  form  <n,n>  are  eliminated  since  they  are  all  single  node 
graphs.  Let  us  make  some  comments  on  each  of  these  subgraphs. 

<1,2>  :  there  is  a  backward  branch  from  node  4  into  it 
<1,3>  :  branches  to  nodes  4  and  5  at  the  exit  node  (node  3) 

<2,3>  :  same  as  above 

<2,9>  :  qualified  as  a  removable  subgraph 

<3,9>  :  there  is  a  backward  branch  out  of  the  subgraph  to  node  2 
<5,8>  :  qualified  as  a  removable  subgraph 

<1,3>  and  <2,3>  are  eliminated  at  Step  3,  <1,2>  is  eliminated  at 
Step  4  and  <3,9>  at  Step  5. 

Suppose  that  the  subgraph  <5,8>  is  replaced  by  a  single  node.  This 
subgraph  has  5  edges  and  4  nodes.  Therefore,  the  complexity  of  the  procedure 
in  Figure  1  is  reduced  by  2*5-4+  1. 
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3.0 


DETAILED  DESCRIPTION  OF  THE  METHOD 


In  this  section,  the  details  of  the  approach  outlined  above  are 
described.  The  concepts  that  are  crucial  to  an  algorithm  are  presented. 

3 . 1  Depth-First  Ordering  of  a  Flow  Graph 

Most  of  our  algorithms  involve  searching  the  nodes  of  the  flow 
graph.  The  way  the  nodes  in  a  flow  graph  are  labeled  is  quite  arbitrary. 
However,  when  these  nodes  are  ordered  in  the  'depthfirst*  fashion,  a  lot  of 
redundant  search  can  be  avoided.  In  this  section,  the  depth-first  search  and 
the  depth-first  ordering  of  a  flow  graph  is  described. 

The  depth-first  search  starts  at  the  initial  node.  At  the  beginning, 
all  nodes  are  marked  unvisited  except  the  initial  node.  At  each  step,  down¬ 
ward  search  from  the  current  node  is  attempted.  If  there  is  any  unvisited 
child  node,  the  child  node  is  marked  visited  and  is  chosen  as  the  new  current 
node,  and  the  search  proceeds  as  before.  If  the  downward  search  is  impossible 
(i.e.,  if  the  current  node  has  no  unvisited  child  nodes  or  no  child  nodes  at 
all),  the  search  returns  to  the  parent  node.  The  parent  node  becomes  the 
current  node  and  another  downward  search  begins.  The  search  stops  when  no 
downward  search  f^om  the  initial  node  is  possible. 

For  example,  consider  the  graph  of  Figure  1.  The  order  in  which  the 
nodes  are  visited  using  depth-first  search  is  as  follows: 

i,  2,  3,  4,  9,  4,  3,  5,  6,  8,  6,  5,  7 ,  5,  3,  2,  1 

The  search  moves  downwards  first.  It  turns  upwards  at  node  9.  Downward  search 
is  attempted  at  node  4  and  fails.  The  search  goes  back  one  more  step  to  node 
3  and  turns  downwards.  It  turns  upwards  again  at  node  8r  downwards  at  node  5, 
upwards  at  node  7,  and  ends  at  node  1.  The  reverse  of  the  order  in  which  the 
nodes  are  last  visited  is  called  the  depth-first  ordering  of  the  flow  graph. 
The  depth-first  ordering  of  the  above  example  is 

1,  2,  3,  5,  7,  6,  8,  4,  9 
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A  general  algorithm  for  performing  the  depth- first  search  of  a  flow 
graph  starting  at  an  arbitrary  node  is  given  in  Section  4. 

3.2  Dominators  and  Subordinates 


A  discussion  of  the  relationship  between  the  entry  node  and  the  exit 
node  of  a  removable  subgraph  is  presented.  The  relationship  may  be  character¬ 
ized  in  terms  of  'dominator'  and  'subordinate*  nodes. 

Consider  two  nodes  of  a  flow  graph,  say  node  i  and  node  j.  Node  i 
is  said  to  dominate  node  j  if  every  path  from  the  initial  node  to  node  j 
passes  through  node  i.  For  example,  in  the  flow  graph  of  Figure  1,  node  3 
dominates  node  8.  On  the  other  hand,  node  8  is  not  dominated  by  node  6.  The 
domination  relation  is  transitive:  if  node  i  dominates  node  j  and  node  j 
dominates  node  k  then  node  i  dominates  node  k.  By  definition,  every  node 
dominates  itself,  and  is  dominated  by  the  initial  node.  In  Section  4  we  give 
an  algorithm  for  constructing  the  tible  of  dominators. 

The  opposite  concept  of  domination  is  subordination.  Node  j  is  a 
subordinate  of  node  i  if  every  path  from  node  i  to  the  terminal  node  passes 
through  node  j.  For  the  flow  graph  of  Figure  I,  node  8  is  a  subordinate  of 
node  6,  but  not  of  node  3. 

Consider  a  removable  subgraph.  Since  it  has  a  unique  entry  node,  the 
entry  node  dominates  every  node  in  the  subgraph.  In  particular,  it  dominates 
the  exit  node.  Similarly,  the  exit  node  is  a  subordinate  of  the  entry  node. 
The  first  step  of  our  procedure  is  to  search  all  pairs  <a,b>  and  select  those 
with  the  property  that  node  a  is  a  dominator  of  node  b  and  node  b  is  a  sub¬ 
ordinate  of  node  a. 

Take  the  flow  graph  of  Figure  I  as  an  example.  It  can  be  seen  that 
node  5  dominates  node  8  and  node  8  is  a  subordinate  of  node  5.  Therefore 
<5,8>  Is  a  qualified  pair.  On  the  other  hand,  although  node  3  dominates  node 
8,  node  8  is  not  a  subordinate  of  node  3.  Therefore,  we  can  disregard  the 
pair  <3,8>. 
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A  separate  algorithm  for  finding  subordinates  is  not  necessary.  In 
fact,  if  we  reverse  all  arrows  in  the  original  flow  graph  and  consider  the 
.."oinal  node  as  the  initial  node  and  vise  versa,  then  node  j  is  a  sub¬ 
ordinate  of  node  i  in  the  original  flow  graph  if  and  only  if  node  j  is  a 
d  ■ aina tor  of  node  i  in  the  reversed  graph.  By  applying  the  dominator  algor¬ 
ithm  to  the  reversed  flow  graph,  the  table  of  subordinates  can  be  obtained. 

3.3  The  Subgraph  Between  Two  Nodes 


Suppose  node  a  is  a  dominator  of  node  b  and  node  b  is  a  subordinate 
of  node  a.  Therefore,  the  portion  of  the  flow  graph  consisting  of  the  nodes 
that  are  dominated  by  node  a  and  have  node  b  as  a  subordinate  as  the  subgraph 
between  node  a  and  node  b  may  be  removed.  For  simplicity,  one  can  denote  the 
subgraph  by  <a,b>  in  the  following.  Using  the  tables  of  dominators  and  sub¬ 
ordinates,  one  can  determine  the  subgraph  easily. 

Consider  the  flow  graph  of  Figure  1.  As  an  example,  the  subgraphs 
' 5 , 8 >  and  <2,9>  are  determined. 

Nodes  that  are  dominated  by  node  5  are:  5,6,7  and  8. 

Nodes  of  which  node  8  is  a  subordinate  are:  5,  6,  7  and  8. 

Therefore  <5,8>  consists  of  nodes  5,  6,  7  and  8. 

Nodes  that  are  dominated  by  node  2  are:  2,  3,  4,  5,  6,  7,  8  and  9. 
Node  9  is  a  subordinate  of  every  node  in  the  graph. 

Therefore  <2,9>  consists  of  nodes  2,  3,  4,  5,  6,  7,  8  and  9. 

3.4  Branch  at  Exit  Node 


By  comparing  the  subgraph  against  the  set  of  child  nodes  of  the  exit 
node,  one  determines  whether  the  subgraph  branches  to  more  than  one  outside 
node  when  exiting.  For  example,  consider  the  subgraph  <5,8>  in  Figure  1.  The 
subgraph  consists  of  nodes  5,  6,  7,  and  8.  The  exit  node,  node  8,  has  two 
child  nodes:  nodes  7  and  9.  Since  node  7  is  in  the  subgraph,  the  subgraph 
exits  to  a  unique  node,  namely  node  9.  On  the  other  hand,  subgraph  <1,3> 
branches  to  nodes  4  and  5. 
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3.5 


Illegal  Branches  Into  the  Subgraph 


Suppose  there  is  a  branch  into  a  subgraph  <a,b>  from  an  outside 
node,  say  node  c.  Then  node  c  is  necessarily  a  descendant  of  node  b.  Other¬ 
wise  there  is  a  path  from  the  initial  node  to  node  c  to  node  b  bypassing  node 
a,  i.e.  node  a  does  not  dominate  node  b. 

Therefore,  to  check  that  there  are  no  illegal  branches  into  a  sub¬ 
graph  <a,b>,  one  checks  that  none  of  the  descendants  of  node  b  has  a  child 
node  in  <a,b>.  This  can  be  done  by  looking  up  the  ancestors-descendants 
table. 


3.6  Illegal  Branches  Out  of  the  Subgraph 


Similarly,  if  there  is  a  branch  out  of  a  subgraph  <a,b>  to  an 
outside  node,  this  outside  node  must  be  an  ancestor  of  node  a.  This  is 
because  node  b  is  a  subordinate  of  node  a. 

Again  the  illegal  branches  out  of  a  subgraph  <a,b>  can  be  detected 
by  looking  up  the  ancestor-descendant  table,  checking  whether  any  of  the 
ancestors  of  node  a  is  a  child  node  of  some  node  in  the  subgraph. 

3.7  Reduction  of  Complexity  Measure 

Suppose  a  removable  subgraph  is  replaced  by  a  node,  then  the  number 
of  edges  in  the  original  graph  is  reduced  by  the  number  of  edges  in  the 
subgraph,  e,  and  the  number  of  nodes  is  reduced  by  (n  -  1),  where  n  is  the 
number  of  nodes  in  the  subgraph.  Since  the  complexity  measure  is  defined  as 

{#  of  edges)  -  (#  of  nodes)  +  2, 

the  complexity  is  reduced  by  e  -  n  +  1 ,  which  is  1  less  than  the  complexity 
of  the  removable  subgraph. 


4.0 


POL  FOR  COrnT!  EXITY  REDUCTION 


Routine  CMPX  RED 


complexity  measure  reduction  routine 


This  routine  accepts  a  flow  graph  as  input  and  returns  to  the 
calling  program  the  reduction  in  complexity  when  removable 
subgraphs  are  condensed  into  single  nodes.  The  difference 
between  McCabe's  complexity  measure  and  this  return  value  is 
McCabe's  essential  complexity  of  the  flow  graph.  The  routine 
also  outputs  the  list  of  the  removed  subgraphs  together  with 
their  complexity  measure. 


generate  data  for  later  references 

CALL  GENO  -  generate  descendant  tree  of  the  input  flow  graph 

....  reverse  input  flow  graph 
....  reverse  arrows  in  the  graph 
CALL  DFORD  with  input  flow  graph  as  argument 

....  arrange  nodes  in  depth-first  order 
CALL  DFORD  with  reversed  graph  as  argument 

-  arrange  nodes  in  reverse  depth-first  order 

CALL  DOMINATOR  with  input  flow  graph  as  argument 

....  generate  dominator  tree  of  the  flow  graph 
CALL  00MINAT0R  with  reversed  graph  as  argument 

-  generate  subordinate  tree  of  the  flow  graph 


initialization 


clear  CONDEMN_LIST 
set  RED  IN  CMPX  to  6 


this  list  accumulate  nodes  belonging  to  removed 
subgraphs 

no  reduction  in  complexity 


o 


Search  for  removable  subgraphs.  Pairs  of  nodes  (node  a,  node  b) 
are  searched  in  the  following  fashion:  node  b  in  the  reverse 
depth-first  order,  and  for  a  fixed  b,  node  a  is  searched  in  the 
depth-first  order.  If  the  subgraph  between  node  a  and  node  b 
is  removable,  the  subgraph  is  listed  in  the  output  and  is 
included  in  the  CONDEMN_LIST.  Nodes  in  the  CONDEMNJLIST  are 
skipped  over  in  our  search. 

00  for  each  node,  in  the  reversed  depth-first  order 
take  this  node  as  EXIT_NQDE 
IF  EXIT_N0DE  is  not  in  the  C0N0EMNJ.IST 

THEN  _  get  the  entry  node 

00  for  each  node,  in  the  depth-first  order 
take  this  node  as  ENTRY  NODE 
IF  ENTRY_NODE  is  the  initial  node  AND  - 
EXIT_N0DE  is  the  terminal  node 

THEN 

CYCLE  _  not  interested 

ENOIF 

IF  ENTRY_NODE  is  not  in  the  C0NDEMN_LIST 
THEN 

IF  ENTRY_NODE  dominates  EXIT_NOOE  AND  - 
EXIT_N0DE  is  subordinate  to  ENTRY_NODE 

THEN 

generate  SUBGRAPH  determined  by  two  nodes 

....  consists  of  nodes  dominated  by 
....  ENTRY_NODE  and  have  EXIT_N0DE 
....  as  a  subordinate 

IF  SUBGRAPH  branches  to  more  than  one  outside  node 
THEN 

CYCLE  ....  subgraph  not  removable 
ENOIF 

IF  there  is  a  branch  into  SUBGRAPH  fROm  a  - 
descendant  node  of  EXIT_N0DE 

THEN 

CYCLE  _  subgraph  not  removable 

ENOIF 

IF  SUBGRAPH  branches  to  an  ancestor  node  of  - 
ENTRY  NODE 

THEN 

CYCLE  _  subgraph  not  removable 

ENOIF 

compute  cmpx( SUBGRAPH) ,  the  complexity  of  SUBGRAPH 
output  SUBGRAPH  and  its  complexity 
RED  IN_CMPX  =  RED  IN  CMPX  +  cmpx ( SUBGRAPH)  -  1 
include  SUBGRAPH  In  CONDEMN_LIST 
ENOIF 
ENOIF 
ENODO 
ENOIF 
ENDOO 

RETURN  RED  IN  CMPX 
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DETERMINATION  OF  HALSTEAD'S  SOFTWARE  SCIENCE  METRICS 


1.0  INTRODUCTION 

Halstead  theorized  a  method  of  analyzing  computer  language  imple¬ 
mented  algorithms  by  evaluating  the  static  expressions  that  make  up  the 
algorithms.  By  identifying  the  operators  and  operands  of  the  expressions  and 
the  number  of  times  each  is  used,  he  defined  measurable  entities  which  serve 
to  evaluate  the  complexity  and  quality  of  the  algorithm's  implementation. 
Furthermore  these  entities  are  general  enough  to  be  applicable  to  various 
computer  languages.  Some  of  these  are: 

N  -  Program  Length 
Y  -  Program  Volume 
L  -  Program  Level 
V*  -  Program  Potential  Volume 
D  -  Difficulty 
E  -  Effort 

The  next  section  explains  in  more  detail  the  derivation  and  meaning 
of  the  above  measures.  Section  3  outlines  one  programming  approach  for 
gathering  data  for  evaluation  by  Halstead's  metrics.  The  fourth  section 
contains  brief  PDL  to  assist  in  program  creation. 
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2.0 


HALSTEAD'S  METRICS 


All  Halstead's  metrics  can  be  defined  by  determining  the  operators 
and  operands  used  in  the  module  under  test  and  keeping  track  of  how  often 
they  are  used  in  executable  statements  of  the  module.  Operators  are  defined 
as  any  symbol  or  keyword  which  specifies  a  specific  algorithmic  action. 
Operands  are  defined  as  any  symbol  which  represents  data. 


Some  examples  of  operators: 


:=  ;  goto 

+  if  .and. 

Some  examples  of  operands: 

SUM  500  1.73 


★ 

begin  ..  end 


"word" 


The  following  variables  represent  information  obtained  from  the 
module  under  evaluation  by  monitoring  operand  and  operator  usage,  which  form 
the  basis  for  determining  Halstead's  metrics. 

nl  =  number  of  unique  operatiors  occurring  in  the  code 
n2  =  number  of  unique  operands 
Nl  =  total  usage  of  al i  operators 
N2  =  total  usage  of  all  operands 

The  next  sections  define  Halstead's  metrics  in  terms  of  the  above 
var iables. 

2.1  Program  Length  -  N 

According  to  Halstead,  the  length  of  a  program  is  the  total  number 
of  times  each  operator  and  operand  is  used. 

M  =■  Ml  ♦  N2 
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2.2 


Program  Volume  -  V 


This  represents  the  size  of  the  program  in  terms  of  bits.  It  is  the 
length  multiplied  by  the  number  of  bits  needed  to  encode  the  implementation's 
vocabulary.  The  vocabulary  is  the  total  number  of  distinct  operators  and 
operands  appearing  in  the  code. 

V  =  N  log2  (nl  +  n2) 

2.3  Prog. am  Level  -  L 


The  values  L  can  take  are  <=  1,  with  a  value  of  1  meaning  that  the 
program  implements  the  algorithm  in  the  most  optimal  and  easily  understood 
manner.  It  is  a  good  indicator  of  a  program's  propensity  for  error  and  ease 
of  understanding. 

L  =  (2  x  n2)/(nl  x  N2) 

2.4  Potential  Volume  -  V* 


The  potential  volume  of  a  program  represents  the  minimal  and  most 
concise  form  the  algorithm  for  which  it  implements  can  take. 

V*  =  (L ) ( V) 

2.5  Difficulty  -  D 


Measures  the  average  number  of  elementary  mental  discriminations 
required  for  each  mental  comparison  needed  to  generate  a  program. 

D  *  1/L 

2.6  Effort  -  E 


E  is  the  total  number  of  elementary  mental  discriminations  which 
were  needed  to  generate  a  given  program. 

E  *  (V)(D)  *  ( V ) /( L ) 
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3.0 


PROGRAMMING  APPROACH 


The  program  to  determine  Halstead's  complexity  metrics  shall  be  re¬ 
ferred  to  as  'program  analyzer'  for  the  remainder  of  this  text.  Two  sources 
of  information  will  be  required  as  input  for  the  program  analyzer.  The  first 
is  the  source  code  to  be  evaluated.  The  second  is  the  set  of  operators  parti¬ 
cular  to  the  language  for  which  the  program  to  be  examined  is  written  in. 
The  program  to  be  evaluated  will  be  scanned  module  per  module,  line  per  line 
for  operators  and  operands.  Each  module  therefore,  will  have  its  own  set  of 
complexity  metrics  associated  with  it  for  which  the  program  analyzer  will 
determine. 

Each  line  of  code  will  be  scanned  and  each  symbol  that  makes  up  the 
line  extracted.  These  symbols  or  'tokens'  are  keywords,  such  as  DO  or  IF,  or 
identifiers,  such  as  X  or  NUM,  or  operators  such  as  <  or  +  ,  and  punctuation 
symbols  such  as  commas  or  parenthesis.  The  following  logic  will  apply  to 
every  token  of  the  module  to  be  analyzed: 

If  the  token  is  an  operator,  it  will  be  placed  in  an  operator  table 
only  if  that  operator  has  not  yet  been  entered.  Also,  an  operator  count 
variable  will  be  incremented.  If  the  token  is  an  operand,  •'  ill  be  placed 
in  an  operand  table  only  if  that  operator  has  not  yet  been  entered.  An 
operand  count  variable  will  also  be  incremented. 

After  the  module  has  been  completely  scanned  and  all  of  its  tokens 
examined,  nl,  n2,  Nl,  and  N2  will  be  determined.  The  length  of  the  operator 
table  will  define  nl.  The  length  of  the  operand  table  will  define  n2.  Nl  will 
be  equal  to  the  value  of  the  operator  co'.nt  variable.  N2  will  be  equal  to  the 
operand  count  value.  Using  tnese  values,  Halstead's  various  metrics  will  be 
computed  and  a  report  output. 
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4.0 


DETAILED  LOGIC 


Initial ize_Tables(operator_tab,  operand_tab  :  ) 

Read  operators 
optab_size  =  0 
opertab_size  =  0 
operator_count  =  0 
operand_count  =  G 
Dowhile  not  EOF 
Gettoken{  :  token) 

If  token  is  an  operator  Then 
Begi  n 

If  token  not  in  operator_tab  Then 
Begin 

optab_size  =  optab_size  +  1 
operator_tab{  optab_size  )  =  token 
End 

operator_count  =  operator_count  +  1 
End 

If  token  is  an  operand  Then 
Begin 

If  token  net  in  operand_tab  Then 
Begin 

opertab_size  =  opertab__$ize  +  l 
operand_tab(  opertab_size  )  3  token 
End 

operand_count  3  operand_count  +  1 
End 

Enddo 

nl  =  optab_size 
n2  a  opertab_size 
Nl  =  operator_count 
N2  s  operand  count 

Ca1culate_Metrics(  nl ,  n2,  Nl,  N2  :  N,  V,  L,  V* ,  d,  E  ) 
Print_Report.(N,  V,  L,  V*.  D,  E  :  ) 

End 


C 
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APPENDIX  L.  DISTRIBUTION  LIST 


Addressee 

Commander 

US  Army  Test  and  Evaluation  Command 
ATTN:  DRSTE-AD-M 
DRSTE-TO 
DRSTE-AD-A 
DRSTE-CT 
DRSTE-CM 

Aberdeen  Proving  Ground,  MD  21005 
Commander 

Defense  Technical  Information  Center 
ATTN:  DTIC-DDR 
Cameron  Station 
Alexandria,  VA  22314 

Commander 

US  Army  Aberdeen  Proving  Ground 

ATTN:  STEAP-MT-M 

Aberdeen  Proving  Ground,  MD  21005 

Commander 

US  Army  Yuma  Proving  Ground 
ATTN:  STEVP-MSA 
Yuma,  AZ  85364 

Commander 

US  Army  Jefferson  Proving  Ground 
ATTN:  STEJP-TD-E 
Madison,  IN  47250 

Commander 

US  Army  Dugway  Proving  Ground 
ATTN:  STEDP-PO-P 
Dugway,  UT  84022 

Commander 

US  Army  Cold  Regions  Test  Center 
ATTN:  STECR-TM 
APO  Seattle  98733 

Commander 

US  Army  Electronic  Proving  Ground 

ATTN:  STEEP-MT-T 

Fort  Huachuca,  AZ  85613 


Addressee 

Commander 

US  Army  Tropic  Test  Center 
ATTN:  STETC-TD-AB 
APO  Miami  34004 

Commander 

US  Army  White  Sands  Missile  Range 
ATTN:  STEWS-AG-AS-AM  (Record  Copy) 
STEWS-TE-PY 

White  Sands  Missile  Range,  NM  88002 


Number 
of  Copies 


1 
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